Reed Me

Development schtuff, SQL Server & other random geekness. Now with more [fill in the blank]!

What year is it? (Or, “what not to do to make your project fail.”)

What year is it? (Or, “what not to do to make your project fail.”)

  • Comments 1

In the immortal words of senior Microsoft consultant from EMEA who shall remain nameless, "What year is it?" The lunchtime discussion one afternoon at TechReady3 (although it doesn't seem like it was a month ago already!) had inevitably turned to the projects that each consultant at the table (from around the world) was currently involved with. Since everyone at the table was a Microsoft employee, the discussion was probably a little more frank and open than you'll typically hear from seasoned consultants...

At one point, a project that was in terrible trouble came up. When the consultant who had inherited the impending disaster described the lack of written customer requirements, the lack of quality assurance activities (formal or otherwise) and all of the other Halloween-type symptoms from stories that Software Development Magazine used to run in October every year (before DDJ swallowed it), the sage consultant from EMEA asked (with due incredulity!), "What year is it? Why do we still have to deal with situations like this in 2006? That's Software 101 stuff you're talking about!"

The discussion (mercifully) turned to the commonalities that we have all faced in projects in trouble – instead of exploring specific open wounds. To summarize, it is our collective experience that even so-called "agile methodologies" are not immune from the basic need to execute the fundamentals: written user requirements, formal quality practices, hiring qualified talent... The symptoms of software projects going (or gone) wrong are legion, and many of them are well beyond the control of consultants (and even outside the actual realm of "software development").

However, there is one single most common practice that seems to be the hallmark symptom of projects in jeopardy. The one thing that is the earliest and most clear warning, in our admittedly anecdotal conversational review, that your project is doomed is a lack of up to date, written requirements. It doesn't seem to matter whether they are use cases, formal specifications or story cards. Just write 'em down and keep 'em up to date! Caveat developer: no written requirements is a sure sign that this project is at risk.

Since it doesn't seem like that much trouble to do a little advance planning and write down requirements (user, functional and non-functional) before anybody begins coding... why is it still so common that people put projects at risk by neglecting this fundamental practice? Whither have all the business analysts gone?!

Leave a Comment
  • Please add 2 and 8 and type the answer here:
  • Post