Please raise your hand if you’ve ever heard someone say the following sentence at the beginning of a project, usually when a specification or some type of design work is mentioned:
“We would like to do it the right way, but we just don’t have the time to on this project.”
20 simple words…and they are used way too many times every day. Pretty much everyone who has worked any significant time on an IT or development job should have their hand raised. This has been used on countless projects as justification to get developers working NOW. This definitely helps upper management sleep better at night, but it is a fool’s sleep. A developer flailing away at an ill-defined problem will not even be half as productive as one that is working against clear requirements and, Heaven forbid, a spec. That plain truth alone should tell us that the small amount of time spent early on for an analysis & design phase more than makes up for itself. But what if that “obvious truth” is really not so truthful at all in reality, kind of like the old “many eyes make bugs shallow” maxim?
It’s not quite scientific (they didn’t have a large enough sample size to make that claim), but let’s use the Standish Group’s “Success Potential” chart they included in their Chaos Report. Team A & Team B are both roughly the same (same number of people, same dedication, same talent level), and they are working on projects that are similar in complexity as well. Team A goes off and starts coding, following the 20 Dumbest Words methodology (20DW from here on). Team B has their designer(s) start meeting with users & project stakeholders to determine the metrics for success. Team B then incorporates that user feedback into a vision & objectives list, and then determines a clear statement of requirements for the project. They then get sign-off and buy-in from the application’s users as well as the project stakeholders and upper management. Their developers have also been spending some time on the project....not coding, but designing out interfaces and making sure that the functional pieces work well together and also fulfill the requirements list.
Some people might say that Team B is way behind Team A at this point because Team A has a mountain of code built, and probably even some early form of what the final product will look like. These same people would probably say that Team A is that much closer to the Finish Line, and will have a greater chance of success than Team B. These people would be completely wrong, however. Using the Success Criteria mentioned above, Team A’s project, even if everything else was perfect (competent, hard-working staff; an executive management committed to success on this project; proper project milestones; full ownership of the project; and users involved with the project), has a predicted success rate of 71%. Not bad, but certainly not great. Not the type of odds you’d want to risk your career on, right? If they take 20DW to their logical conclusion, and just roll-out a project that they “know the users want”, that success rate drops down to 52%. Yikes! For the record, Project Team B has a 100% predicted success rate. Again, this is an imperfect calculation because it "only" involved a little more than 8,000 projects, but it's a lot better than gut instinct! There's a link to the full report at the bottom.
So let’s go back to our pointy-haired manager. He’s just uttered the 20DW, and usually follows it up with some call to action like “now let’s roll up our sleeves and get to work”, or, even worse, something about cheese being moved around that he read in a trendy management book. Then he goes back to his office for a furious morning of “power” e-mails and a non-fat mocha chino. If I’m working too hard to paint this as a caricature of buffoonery, it’s because that’s what we need to recognize it as. If the success rates of IT roll-outs & software development projects are ever going to significantly change, we have to start at the beginning, and this is it as far as the development staff is concerned.
A piece of software doesn’t start with the first line of code. It starts with a request or an idea. It then cascades into various different forms, and eventually management agrees that work should start on it. It’s at this point that we’ll start, since this is the beginning of the formal software development lifecycle and most IT people weren’t included at the earlier levels (Author’s Note: this is a big mistake for businesses as well, but I’m only going to try to part the Red Sea with this blog, and not yet take on the Pacific Ocean).
It’s at this time that you usually hear 20DW for the first time. It may come up later when someone mentions a test plan or staged roll-out, but most of the time it's uttered pre-design. And yes, you should loathe 20DW. This statement of 20 common words is the most ignorant and damaging statement of all, because it ignores one of the first basic lessons of the software development lifecycle: for all but the simplest projects, spending 15-35% of the total expected project time on design will save you at least that much in development time, if not significantly more. And that design doesn’t mean “screenshots and wireframes”, it means starting at the beginning before you move on to the functional design or, even worse, the architectural design. That document, which can be called any 1 of 100 different common names ('Software Elements Analysis' & 'Functional Spec' are my two favorites, the latter because you should have this info right before your functional design begins), should begin with the following 3 sections. If this seems like a relatively brief description of something so important, you’re right. I’ll cover these in greater depth in my future blogs.
· The Vision – One sentence succinctly describing what you want to deliver. It’s hard to come up with a vision because it takes creativity to really capture the essence of a project, but this sets the tone for the entire project and should be the perfect answer to anyone asking “What does it do?" If you've ever answered that question with a list of random features, you probably didn't have a good vision for that project.
· The Objectives – The 3-5 (usually) most important goals of this project. These are used as the litmus test for all requirements, new features, or change requests during the design & development of the project. If a feature isn’t actively contributing to at least one objective, then you’re introducing feature creep and need to consider if this is really proper to do this now, or whether it’s right to handle that request in another project. If it’s urgent, go ahead and spike off a small team to deal with that request specifically, but always try to keep your projects true to their original purpose.
· Requirements – This is the list of every major guideline, feature, or option that the product will support. It’s OK to mix guidelines like “Will follow the Windows logo requirements for application development” with features like “Allows users to delete records”, although I do find that it helps to group them by each such function. But the real key is to make sure that this is an exhaustive list, and then prioritize them accordingly. This can be a simple system, such as labeling something as 1, 2, or 3 in priority, and then keeping a separate list for the requirements that have been explicitly thrown out of the project. 1 means “Must have”, 2 means “would like to have”, and 3 means “probably in a future release”.
A lot of people call this “overhead.” This is the very reason that 20DW came into being in the first place. But it’s not overhead; it’s actually the beginning of a successful, well-managed project. From this up-front work of Vision, Objectives, and Requirements, it’s possible to determine who your users are, map out the user scenarios, and start designing the functional pieces of the software, which snowballs into the beginning of code development. All of this moves along rather easily because someone spent about 5% of the total number of days allotted for the project investigating the request, conducting user interviews, and getting these 3 key pieces reviewed & signed off on by management and a representative user group.
I'm not saying that you can do these 3 sections and then let everything else fall by the wayside...that's just not the way software development works. You've got to cover a lot of different ground, and then have the willpower to follow-through on a project that just doesn't have any more interesting problems to solve, but a ton of work remains. But that design work can help you in the end-game as well. Anyone ever had trouble figuring out how to prioritize bugs, or handle change requests? These 3 sections are your guide for dealing with them. It's much easier to make the "tough decisions" late in the project when you have a solid footing that you've built your project on. These 3 items help in other ways as well. They are the groundwork that keep the regular nightmares of software development at bay: you don’t need developers doing re-writes when there are clear, unchanging requirements underneath the design of their feature; you don’t waste time developing features the customer doesn’t need, because you know exactly what they need; and, ultimately, you don’t alienate and/or dissatisfy the customer with a product that doesn’t quite do what they expected it to.
Now I’d like for you to think back to the last time you heard it, and try to remember how that project went. No one can hear your thoughts, so be honest with yourself.
-
Was the project delivered on time? No, not on the date that y'all picked 3 weeks before ship, but the deadline that was given early in the project?
-
Was the project delivered on budget? Did you use more resources, internal or external, than you expected? Was the hardware necessary for deployment properly identified early on?
-
Did the product ship with a full feature list? Note that I'm not asking about everything that the user asked for (such a project would NEVER be complete if your users are the same as mine!), but instead I'm asking about what was initially believed would be in the product.
Probably a “no” on at least two of those, right? In fact, if you’ve worked on a project governed by 20DW, and can still answer all 3 of those questions with a “yes”, then you were working on a project that just wasn’t that complicated, or you got pretty lucky. And lucky is never bad, but just don’t believe that you can reproduce luck, because it doesn’t work that way.
Finally, ask yourself "If my company is guilty of this, how can it be changed?"
In many companies, one person can’t make this kind of change...management just doesn't trust any one person enough (Author's Note: this is another mistake of most companies, but it's reality). Band together with a few of your teammates that feel the same way you do, and ask for a trial period of a project or two. Run that project side-by-side with a similar project (roughly the same resources, same complexity of the program, etc) that is following 20DW, and call it the “Pepsi Challenge” of Software Development. In other words, have fun with it, and evaluate the differences for yourself. It’s probably best to decide on the metrics beforehand and even have a “3rd party” judge, i.e. someone that isn’t on either product team and has no vested interest either way. My experience is that you’ll see a significant difference in the quality of the product (proven out by the number & severity of the support requests after release), the customer satisfaction survey results, and the man-hours allotted to build that product. Those 3 also just happen to be the metrics I’d recommend for your competition as well, because, in the end, those are the only 3 things you really care about when evaluating a software project after-the-fact. If you take care of those three, then everything else is nitpicking.
Good luck in all of your projects, and please bear with me while I get better at this. Here is the link to a PDF of the Standish Group's Chaos Report.
Tools 
Help
Loading...
