Rolling wave planning works well for software development projects.

There is a high degree of uncertainty when gathering requirements or putting together a specification.  The challenge in finding the right terms alone, leads to many potential misunderstandings between project sponsors, managers and team members. It can be hard to find the boundary terms that mean the same thing to everyone.

Because of this, when its doable, prototyping is worth more than spec’ing.  This can be a UI prototype or a functional prototype or even a screen by screen step-through. But a prototype helps accelerate the conversation between sponsors and team members, and reduces the level of uncertainty (and therefore reduces opportunities for wasted effort).

As an aside, this is often what people are looking for when they turn to Agile project management: repeated prototyping.  What draws many people to Agile is the idea of delivering a meaningful and scope controlled prototype, as fast as possible, and iterating from there.  That is a central concept behind rolling wave planning.

For many of these circumstances, rolling wave planning with prototyping is a better fit.

One difference between Agile and rolling wave planning is that rolling wave planning doesn’t tightly define the turnaround times for delivering features or a prototype.  The project manager is not tied to a pre-defined period for delivering the prototype.  Project managers can select the appropriate time period for each iteration.

A software developer deals with unique situations almost every day.

Every project, every bug fix, every issue has its own unique challenges and one of a kind circumstances.

Even if the functionality has been built before in other systems or is available on other pieces of software, implementing it on a specific system or integrating it with existing code has its own set of challenges.  A developer really does work on “projects” in the sense that they work on unique endeavors that have some degree of uncertainty and risk of failure.

As far as the other side of the formal definition of a project, having a defined start and end date, that’s often a matter of controlling scope creep or change requests

Because developers are working on projects there is no single body of knowledge they can master to have answers to questions right off the bat.

When you ask a doctor about a pain in your side, there is a well documented set of potential answers and a huge body of research on the most probable answer based on other data points/symptoms reported.   They can usually give you an answer off the cuff.  And if not, there are prescribed recommend tests to further find the answer.  This isn’t the case with a software developer.

A software developer is not a doctor. No two bodies of code are the same.

Next time you ask a developer for an answer or an estimate, don’t surprised if they need time to come up with the answer. Or, if the answer they give is inaccurate or if the estimate is off.

The same is true of designers and creative knowledge workers.

Peter H. Feiler and Jorgen Hansson from the Software Engineering Institute (SEI) have compiled and published some interesting statistics that point to the benefit of finding and fixing bugs early in a software development project.

There is a huge benefit to finding and fixing problems early.

Here are some of the most remarkable findings:

• 70% of faults are introduced in the early stages of a project lifecycle.
• But, only 3.5% of faults are found at that stage.

• 80% of faults are actually only found in the later stages of a project’s lifecycle.

• The cost of fixing faults in the early stages is 2.5x.
• The cost of fixing faults in later stages is 16x or higher.

According to the research you can save yourself over 600% on repair and rework costs on a project by finding and fixing problems early.

While this data is specifically for software development, the conclusion rings true for projects of all sorts, including marketing projects, creative work, manufacturing or research projects.

1. DON’T OVERPLAN
2. Change the plan as needed
3. The more you invest in a plan the less likely you are to want to change it
4. The more you invest in a plan the less likely your team will be to give you accurate information
5. Leave room in your schedule for changes to the plan
6. Don’t try to predict everything that will go wrong
7. Just leave room in your schedule for things to go wrong
8. Not every process can be dissected into easy to monitor steps
9. Let team members update the status of their tasks

10. FEAR SILENCE
11. Keep stakeholders appraised of your progress, always
12. Tell stakeholders ahead of time when the plan looks like it’ll need to change
13. Insist on feedback from your team on their progress
14. Give your team the detailed blueprints they need to develop
15. Don’t ask your client or stakeholders to build that blueprint
16. Don’t even ask your client to sign-off on the blueprint
17. Spend time understanding your client’s needs, in detail
18. Spend time understanding your team’s skills and abilities
19. Trust the feedback you get from your team
21. Relay relevant information to your client
22. Communicate always -especially when things go wrong.

23. TEST EXTENSIVELY
24. Test early and often
25. Test proven techniques a lot
26. Test innovation even more
27. Test functionality to make sure it works
28. Test the implementation of it to make sure the functionality works when put into a workflow
29. Test its deployment to make sure the functionality works in the users’ technology environment
30. Monitor users’ interactions with your solution to make sure it works for the user and that the user gets it
31. The latest greatest techniques are not always the best solution.
32. Users prefer not to learn new habits
33. Find solutions that seem effortless to your users

I’ll have the pleasure of speaking to the Mid-Michigan ColdFusion Users Group on January 8th at 7pm. 

The topic will be software development and design -specifically addressing the importance of adoption and factors that can improve adoption.  This will include a discussion on the use of AJAX, Flash in an interface and how to choose and design specific functionality.

Here are the directions to the user group meeting.

Please feel free to stop on by.

My recent presentation on software development and the importance of useability is available online. 

Thank you to Charlie Arehart and the Online ColdFusion User Group for hosting and recording the event.

Thank you, as well, to everyone who participated in the question and answer period.

I will be speaking this Thursday, October 26 at 6 pm ET at the online ColdFusion User Group run by Charlie Arehart. The topic is on building software that people will use.

http://coldfusion.meetup.com/17/boards/view/viewthread?thread=3722239

You can join in from anywhere - so feel free to stop on by.

Its a week past due but thank you to the Charlotte Adobe Users Group.  Had a great time with great people and lots of good conversation (both during and after the meeting). 

We talked about everything from software design, user adoption and project management to where is Adobe and ColdFusion going, and what technologies will stand the test of time.

Thank you to Sutton for putting it all together, to Lodestone Digital to hosting and to everyone who attended.

I’ll be speaking to software developers at the Detroit Area ColdFusion Users’ Group (DETCFUG) meeting on Wednesday, August 8 at 6 pm ET. Come on by.

To attend or for more information visit http://www.detcfug.org/cfug/meetingSingle.cfm?meetingID=23.

The topic will be effective project management, particularly for development projects and IT implementations. I’ll also be giving a walk-through of Vertabase Pro, an enterprise project management application written in Adobe’s ColdFusion.

Jeff Peters has a nice article in ColdFusion Developer’s Journal giving an overview on some of the basics that can be accomplished when using an organized project management process for development using project management software available from www.GrokFusebox.com.

There are an additional set of project management software tools that can surround the software development process as a whole, providing a framework in which the development work takes place. Functionality in this framework includes tracking tasks, priorities, resource allocation across projects or a department and budgetary tracking and reporting.

These features create a more positive environment for software development or for a software development project.

Essentially, with minimal data input from a developer, management can get all the data they need to monitor the project or portfolio of projects (which they’re going to do anyway), without having to interrupt the developers or waste people’s time in meetings.

Vertabase Pro is a ColdFusion based project management software tool that does just this. You can get a look at it by checking out a screenshot tour or requesting a test drive.

Nothing is going to be easier than just being left alone to do your work. But these kind of project management tools can make a big impact on the overall long-term success of a software development project or IT department within a company or in a client/developer relationship.