No more Software Development Blame Game…

I remember in the 1990’s when the crevasse between software developers and customers supposedly was solved by adding business analysts to project teams. No longer was there an ‘us’ and ‘them’ mentality (if you believed the promoters) but rather a cohesive partnership with both sides singing “Kum ba yah” and working as a team in harmony.  The 1996 CHAOS report (not-withstanding the issues with the exact percentages which was the subject of my recent post) announced that software projects were successful only 1/6 of the time (16%). A decade later, the numbers have doubled to so that today, about 1/3 of software projects being proclaimed as successful. Much of the increase can be attributed to advancements made by the software development community in terms of technology and process improvements.

Yet, we’ve still got failures and rework (rework accounts for between 40% and 45% of software development effort depending on the source) and dissatisfied customers.  And we’ve got dysfunction in project initiation fueled by the apathy (and technology ignorance) by acquirers and customers, and the burden of fixed price contracts (allowing for limited flexibility) on the part of suppliers.  So we begin project at a deficit point (lack of customer engagement and inflexibility of fixed price contracts for poorly scoped work), and when changes happen – it compounds the situation.  While the customer argues that new requests for functionality are actually clarifications to the original scope of work, the supplier argues that such requests are changes to the scope and should be paid for as change orders.

The resultant blame game (whose fault was it that there is a change or clarification or modification) is unproductive for the partnership or teams or whatever you want to call the customer / supplier relationship.  It’s not a problem of the software development or construction processes, it’s a more insidious problem of lack of scope management.

Sometimes it helps to use an analogy to clarify the situation for non-technical customers:  Say I need a restaurant or  maybe a b&b (bed and breakfast) built, the site landscaped, and a parking lot for cars (and maybe even a boat dock for patrons).  If  I ask a builder to give me a firm fixed price (based on their past experience with similar work) – it is easy to see the intrinsic risks of fixed pricing:  what if the site is in Alaska versus Miami, what if I choose a mountainous area versus the plains?  What if I decide I want more seating than originally thought?  What if the bed and breakfast becomes a spa, bed and breakfast?  What if I need to dig a channel to connect the main waterways with the restaurant for boats? The “project” is in fact a combination of many potential projects (each will need a separate estimating equation) and the lack of solid requirements and choice of site (with its building code) impedes exact pricing.  If I do engage a builder to do such work – there are so many assumptions built into the price that the flexibility to make changes throughout the project will be minimal.  On the other hand if we were given solid requirements, customer engagement and approval, and a specific site, the work would progress through the construction project with far less issue.

So, too with software development.  Premature fixed price contracts where multiple projects are involved (within the context of a single ‘business  project’) are destined to fail.  There isn’t an oracle on earth who can accurately predict the cost of a software development program prior to requirements – and yet customer management routinely insists that it can be done.

Here’s where the dysfunction  lies – it’s not up to a business analyst to scope out, size, explain the importance of involvement and engagement to the customer, subdivide the “project” into component sub-projects (e.g., migration, enhancement, new development, and conversion projects are all typically lumped into a single scope of work by the well-intentioned but ill-advised customer), chart the progress against the baseline, manage and assess the impact of change on the suite of projects, etc.  The customer is often left to their own (technology ignorant) devices to know what, where and how they need to be involved as the construction begins and progresses.

In building construction, there is a general contractor or architect over the entire job – in software development, we have a myriad of people who profess to do so – but given the industry success rates, we’re not succeeding with the traditional approach.  And blaming each other when things don’t go right is downright unproductive and a drain on morale.

This is where a Certified Scope Manager (CSM) can make a big impact on software development.  The building/construction processes in software development are not broken – they work fine as long as there are good requirements (even good user stories!), it is the customer interface and flawed fixed pricing that is the problem.  A certified scope manager works on behalf of the customer/ acquirer and subdivides the scope of work into independently managed sub-projects.  Then the scope manager works together with the customer to document high level requirements (both functional and quality requirements) for each sub-project – and creates one or more RFP’s (requests for proposal) from suppliers.

The suppliers do not bid based on fixed price but rather on unit pricing ($ per Function Point or $ per hour as applicable) for each piece. At this point, the scope manager works with the customer to assess the bids (and compares them to benchmark unit prices for similar completed work) and award the contract(s) to suppliers.

At this point, the customer and supplier work together through requirements/ use cases/ user stories to determine the work to be done. The scope manager does not take part in the requirements or development, but simply creates a baseline of the functional size as the requirements roll-out and move into the construction phases.  With a baseline size, the customer can figure out the overall anticipated cost of each sub-project based on unit pricing.  The scope manager obtains progress reporting from the supplier as development progresses and reports such (in terms of functionality delivered or progress made) back to the customer.

Whenever changes occur, the scope manager (still acting objectively and on behalf of the customer) assesses the impact of including the change in the project and allocates payment for work done to date prior to the change. Throughout the project, the scope manager keeps track of all the work (prior to and after changes are made) that the supplier does to deliver the functionality requested by the customer. The Blame Game stops here!  Changes or clarifications or modifications to specs or whatever you want to call them are analyzed, assessed and the impact of incorporating them into the project is done objectively and the supplier will be paid for work done up to the point of change, and for customer directed changes. It no longer matters why there is deviation from the plan – it is simply a matter of include / exclude and the supplier no longer runs the risk of doing customer directed work for which they won’t be paid. (This is a major difference with unit pricing versus fixed pricing. Flexibility and change are easy with unit pricing!)

Ultimately the software solution(s) are completed and the scope manager assesses the overall delivery and tells the customer what amounts are owed the supplier based on work done and the unit pricing they agreed to during the contract awarding phase.

The last step (which unfortunately is another area often forgotten once the project is done) is to capture all the project data (actual hours expended, functionality actually delivered, lessons learned, etc) and record it in a knowledge database so that the next project can gain from this project.

It’s all common sense and contained in the northernSCOPE(TM) approach developed by the Finnish Software Measurement Association (FiSMA).  And, Certified Scope Manager training is now available in the United States.

Here’s a couple of articles I’ve written if you are interested in more information:

– Achieving Olympic Success… with Scope Management

– Scope management – 12 steps to ICT project recovery

Agile has made great strides in software development- but doesn’t cover the same focus with customers as scope management does. A scope manager works effectively with the customer and project teams on agile projects – but is not part of the project team.

Why not attend the upcoming Certified Scope Manager (CSM) training coming up in Tampa, FL April 26-30, 2010? Get out of the Blame Game and into productive software development – with scope management!

To your successful projects!

Carol