Kablingy

As a consultancy,  how can we define project success?

Typically in a project, a client asks for features and a software development consultancy delivers those features, hopefully on time, on budget and to a professional standard. Then everybody claims success.

But how do we know if it was a success? Did we really fail? Could we do better than this?

We think the best way to address  project success is to first understand the project stakeholders' real requirements. The problem is that even the most enlightened agile developer can mistake features and designas project requirements. But by continually asking why, and not how, we can fish out what the client really requires. Consider the following example:

A sample set of  so called "requirements"

The client needs us to develop a web application with the following must have features:

• Users can sign up for free and upload and sell their own books
• Room for Google ads, and sponsors.
• User can upload their own avator and connect to  authors of the same genre
• Forums
• Integration with MySpace, Twitter
• Facebook App

This is not untypical of the kinds of applications we are asked to build. However, if we continually ask our client why (5 times will do the job) she wants these features, we might actually get to the real requirement which is:

The client wishes to increase her passive income by €2000 euro a month, within 6 months

Now that's a requirement and that's exactly where we should start the conversation.  Now we can start to talk about things like the business model  e.g.

• Why is she offering a free sign up? Why not charge her users a flat fee per month or percentage of the sales? 50 subscribers on a €40 a month plan will achieve the goal in a more predictable manner than advertising. Not to mention, can she realistically get enough traffic within 6 months to justify the advertisers fee?
• We might ask her if she would consider trying to aim her product at businesses instead of the consumer, since businesses are usually happy to pay for services, while consumers expect everything for free. Would she consider working with a dedicated sales team to get those 50 subscriptions within 6 months?
• Why bother inventing adding social network features when she could integrate with another established one or avail of a social networking platform service. Will the social network aspect help her to achieve the €2000 in 6 months goal at all?

And so on. You can see how this way of thinking can drastically alter the list of must have features from above. Perhaps the feature list now looks like this:

• Build a subscription based service aimed at professional authors. Authors get a shopping cart and microsite CMS with a spot for video blogging. Charge 40 euro a month for this service.
• Sample chapter of the book can be downloaded as a watermarked PDF
• Offer an auxillary service connecting authors with publishing companies

So coming back to the title of this post, how could we define project success? How about this.

• Get the real requirements. Make sure they have been quantified. If you're feeling saucy, you could even consider a requirements specification language like planguage. Don't be put off by the phrasespecification language, it's quite accessible really and not at all stuffy.
• Get your stakeholders to prioritise the top 10 requirements. Each requirement fits on an A4 sheet of paper. There's no need to mention features - that's for the design and development team to figure out.
• Drive the design from these requirements
• Then, do all of your usual wireframing, test driven development, iterative planning, continuous integration and all that good stuff etc.
• Measure continuously and communicate with your stakeholders on whether the requirements are being met, and thus if the project is going to be a success.

The masters in this department are Tom and Kai Gilb. Take a look at their site, publications, and free books for a wealth of information on requirements gathering and measuring project success. It's exactly what's been missing in the Agile software movement.