Project Management 101: Creating the Right Ripple

Most software projects fail. Only about a quarter are completely successful. About half are late and over budget and the remaining quarter just fade into oblivion. What if there was a simple way to ensure your project’s success? There is, and it’s all about starting out in the right way…

It has just finished raining. From my home office I can see the backyard pool. Drops of rain that have been clinging to the screen porch are finally yielding to gravity and plummeting into the pool. Each drop disturbs the previously placid surface of the pool, but the effect is very different in each case. Some cause large ripples and some small, some fall too close to the pool edge causing an irregular pattern. Sometimes many drops hit the surface in quick succession causing complex interference. Occasionally…just occasionally…the “right” drop of water falls bang in the middle of the pool and irradiates out in perfect, beautiful circles. If I study this scene for long enough I will be able to work out what is required of the drop so that it is most likely to cause this perfect ripple…the size and shape of the droplet, the beam from which it must originate, the point along that beam from which it must fall, and so on. This in essence is, or at least should be, the goal of the planning stage of any project: defining the conditions that will cause that “perfect ripple”. The “wrong” droplet will cause imperfections and irregularities in the ripple, which become more obvious the further it irradiates from the point of impact. In just the same way, any deficiencies in your planning will only become more and more obvious as the project progresses.

So how do we create the right ripple?

Deming’s 15/85 Rule

W. Edwards Deming is a brilliant business consultant who revolutionized many companies and organizations in the 40 years following World War II. He established fourteen groundbreaking management principles that can be applied to just about any organization. Among these, Mr. Deming propounded a fundamental principle on which all software projects should be based. It’s simple really. If you get the first 15% of a project done correctly, you will ensure at least 85% of the desired outcome. That first drop of water that disturbs the surface of the pool is your first 15%. The resulting ripples, right or wrong, all have their origins in that single drop.

Some of you will be old enough to remember when products made in Japan were treated with broad scepticism. Toyota and Honda cars, for example, were regarded by some as third-rate death traps that no one in there right mind would want to buy. Certainly the reality is that the overall quality of Japanese products was nowhere near the standards they have attained today. So what changed? American industry largely dismissed W. Edwards Deming but his management concepts were firmly embraced by Japanese manufacturing companies. In just a few short years the trend of quality was completely reversed leaving the American big three auto manufacturers scratching their heads and trying to figure out how to get back into a game they used to control. That’s what W. Edward Deming did for Japanese manufacturing, and we can apply those same concepts to software development.

Think about the best projects you’ve been a part of in your career. How many were 100% successful? On how many projects would you have been happy to achieve 85% of your stated goal? I’m not advocating that achieving 85% is sufficient, but if you could ensure such a high success rate, just by getting the first steps right, then doesn’t that make the remaining 15% that much easier to achieve? I believe it does.

The Genius of Stradivarius

Though he never knew it, Stradivarius provides a perfect illustration of Deming’s 15/85 rule. Today his top instruments are worth millions and are coveted by such luminaries as Itzhak Perlman. Many attempts have been made of over the years to recreate the genius of Stradivarius. They have taken apart his violins, measured every point with calipers, and then reproduced a copy of the violin to the exact same specification. This created a nice instrument, but one that still fell some way short of reproducing the sound quality of a Stradivarius.

It is only recently that the true source of Strad’s genius has been revealed. He lived at a time when the world was just coming out an unusually cold era. Trees grow less in the cold and so the wood Stradivarius was harvesting was coming from trees with unusually tight rings. Some theorize that it goes much further than this and that perhaps Strad had a natural gift for picking the right trees to harvest, or that his instruments may all have come from just a few trees. Whatever his secrets were, his instruments are made from a fine, dense wood that provides a perfect tonal quality. That wood was the 15% “right start” that Stradivarius needed to produce 85% of a master piece. His natural talent as an instrument maker took care of the other 15%.

Implementing Deming’s Lessons in Software Development

For Stradivarius his first drop into the pool was selection of the right starting materials and the resulting ripples have echoed for centuries. For software developers, the key to getting that perfect first drop is simple: communication. By this I mean direct communication between the client and the whole project team, right from day one.

Effective Communication

Think about how a project typically starts. For a typical consulting firm, the process might look something like this:

1. A salesman meets with the client.
2. A project manager is brought in and the requirements are taken from the client.
3. The PM writes a requirements doc and turns it over to a software architect who designs the solution.
4. The design is imparted to the development team, assignments are made and coding begins.
5. The PM gets the testing people involved and the process will be imparted to them. The testers will probably get the specifics from the developers.

And so knowledge passes from the client to the PM to the architect to the developers to the testers. If you have ever played the telephone game (a.k.a. Chinese Whispers) you will instantly spot the flaw in this approach and understand why it is unlikely to yield that perfect 15% start.

I am convinced that communication with everyone in the team is absolutely fundamental to achieving that perfect start. I must admit I have rarely got my superiors to buy into this process but on the couple of occasions I have, the results were stunning.

During one particular period, we were experiencing a lot of technical success but our projects were constantly behind schedule. After careful documentation and analysis I was able to prove that scope creep was the culprit, and that this was a result of inefficient communication with our clients and among the team. With an eight month project on the horizon that could not miss its delivery date, I finally got buy in from management to bring the whole team on board from day one.

Joint Application Development

Essentially, I implemented a Joint Application Development (JAD) methodology. Everyone, from testers to junior developers and interns, participated in every meeting with the client. There was no endless communication string; everyone got their knowledge first hand. The entire development team, the client and anyone who had discrete business knowledge of the problem space, assembled in a room. The goal of these meetings was to:

• Define the problem/s that the solution is expected to solve
• Define each process -think use case – in the system in exact detail
• Define screen layouts
• Walk through each process with screen shots, roll play if necessary – people will often seeing missing steps when this is done repeatedly. If a new step is added start over again
• Define a complete and specific requirements document that the solution will be based on
• Get the client and the whole team to sign-off on the requirements document

By walking through each process and clarifying every detail with the client, and the entire team, we effectively killed scope creep. The client was confident that we understood their needs. In place of vague statements such as “we need a page to create customers”, we had sign-off on a clear, concise requirements document of the following form:

The system will maintain a list of customers. A customer record with be defined as:

• Customer ID – System Generated
• First Name
• Last Name
• Full Address (2 address fields, city state and postal code)
• Phone Number
• Email address

Each field with the exception of Customer ID will be fully editable. A drop-down list will be used to select a state. Validations include:

• First Name – required
• Last Name – required
• Postal Code- Required, must be 5 or 9 numbers only
• Phone Number – 9 numbers only
• Email Address – valid format, no anonymous accounts (Yahoo, Hotmail, GMail etc)

You will reach the customer edit page thought a search engine that allows you to search for customers on any combination of the following fields.

• First Name
• Last Name
• Postal Code

…And so on…

Every member of the team, from software testers to developers to project managers, understood these requirements and was able to articulate the system procedures. The result was a project that was delivered, completely tested and bug free, on schedule and on budget. No overtime was required and contingency funds were never used. We had success and a model on which to move forward, and our department used it to deliver a string of large, successful projects.

Conclusion

In my opinion this process of extracting from the client exactly what it is that they need, and making sure everyone in the team understands it, is the critical first 15% that is going to ensure you achieve at least 85% of the project’s goals. Once complete, you can hand the requirements doc over to the architect and let him do his thing. Your project managers can start scheduling and working on the project plan. You’ve got the project off on the right foot. Everyone is heading in the same direction. This is no small task.

It is this process that will define the first drop that is about to disturb the calm surface. Get it right and the resulting ripples will be a joy to behold. Get it wrong and the ripples be irregular, will interfere and overlap, and your project may be doomed to scope- and budget-creep, or even outright failure, like so many others before it.