Software Project Management: Traditional Waterfall Methods Are Not Structured Enough

November 26, 2009 at 4:09 pm 2 comments

As a developer, the key metric for making up my mind about the likelihood of a project plan leading to a successful outcome is whether it tells me something about the time which will elapse between a feature being specified and when QA feedback about it is available.

Reviewed a proposed project plan today. Here’s an excerpt from my notes:

The phases following the discovery / design phase are shown as  development, testing and integration.  The reason why it might be better to structure iterations along the lines of delivered product features instead is because a design/development/testing/integration phase approach isn’t structured enough to allow for meaningful risk mitigation: Something more agile would be better.

One important activity for a dev team is to assess a proposed project plan for how likely it is to result in a successful outcome.  Looking at this from a developer’s perspective there is one (… in my opinion, very nearly the only relevant one…) key metric:  How explicit is the plan in telling me the amount of time which elapses between a given feature being specified and  us getting QA feedback on whether it works? A waterfall project with design/develop/test/deploy phases is not structured enough to make this information visible.

Knowing the QA feedback lag is vital because the longer a bug or missed requirement remains undetected, the more expensive it becomes to deal with it.  Without explicit information about what this time interval is likely to be, I can’t begin to optimize things in order to shorten it. The reason why I need to shorten this cycle is because if it’s too long (or worse, random or unknown), I am flying blind: No realistic assessment of  project status is possible, therefore I cannot mitigate risk.

My experience is that it is not impossible to deliver successful work following a design/develop/test/integrate/deploy style project plan if the client insists, as long as the budget and timeline take the resulting overhead into consideration:

– Additional  development and QA effort to deal with the increased number and complexity of defects.

– Additional PM time necessary to establish project status and to translate status reports, etc. from what is happening on the ground to what clients expect to see. (Project status is of course an approximation: With long QA feedback cycles, the actual status can be totally different from what it was at the time of doing QA).

Advertisements

Entry filed under: Agile Project Management.

Slides from “Evolution of Software Architectures” UxCamp Vancouver Impressions: “Developers Have User Experiences Too ….”

2 Comments Add your own

  • 1. waterfall  |  November 27, 2009 at 8:05 am

    Waterfall and agile are two unique development models used in interactive and software production. It’s likely the debate over which is better will continue indefinitely, but in reality, both approaches boast significant but different benefits. It’s generally accepted that agile, specifically, lends itself well to software development and large-scale website projects. Although a novice Project Manager may feel more comfortable working with a waterfall approach because each step is predictable, letting go of the familiar may well be worth it to make the move to an agile model. The collaboration and flexibility that agile brings can result in a better end product for your client, and a more engaged, harmonious internal team.

    Reply
  • 2. Louis Lota  |  December 21, 2009 at 10:36 am

    Really well-written article, thank you for writing about this. You have a lot of really good information on this site, thanks again! I found a brief primer on Software Testing, do you think it is any good? I’m curious about such introductory articles for someone who is thinking about getting into Testing. Visit my site if you’d like to read more.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Twitter

   @robertreppel

%d bloggers like this: