Introduction

I’ve been working in the software industry for over 30 years and one thing hasn’t changed in that time. Clients, quite understandably, continue to want software delivered on time and on budget. For software developers, like our company, this is the base requirement that we live with on every project with every client.

In my time I’ve been party to many successful projects and some that were “challenged”. Each project is a learning experience but as with most things in life you actually learn more from the difficult projects than from the ones that go fairly smoothly.

So if you’re a project sponsor or stakeholder who wants their software delivered on time and on budget then I’d like to offer some advice from the trenches about how you can help the project team meet your targets.

Of course this advice is coming from the supplier side but our reputation as a software developer is built on successfully delivering projects so we are just as keen as our clients to see a project succeed.

It’s a two-way contract

Whether you are procuring services from your internal I.T. department or from an external provider remember that there are two sides to each project – the user community who want the system and the project team tasked with delivering the software. Each has a vital role to play.

On most projects that I’ve worked on the project team is usually 100% dedicated to the project through to completion. So the team will be fully focussed on delivering according to the timeline and budget.

However, the project team’s commitment is just one side of the equation. They also need the project stakeholders and user community to be as committed to the timescales and budget. This may sound odd but I’ve seen situations where, once the contract has been awarded, the project responsibility seems to become the sole preserve of the IT team.

Let’s be clear here – your project is doomed if you see it as a one-sided contract. It doesn’t matter how good the project team is they will not succeed without commitment from the user community and project stakeholders.

The most successful projects I’ve worked on are the ones where both sides work collaboratively, are committed to the same goals and where there is shared responsibility for the project’s success.

Is the budget really more important than the feature set?

This is the crucial question that will determine the success of the project. Most contracts are negotiated based on the project team’s commitment to an agreed budget. However, on many projects once the analysis phase begins, slowly but surely the project gets driven by the features that the software apparently must have with a disregard to the cost of implementing those features.

Don’t get me wrong. I’m not talking here about limiting the essential functionality of the system. All software must have a minimum set of functionality to be useful and that will vary from project to project.

What I am saying is that it is not possible to continue to demand an ever increasing number of features and still expect the project to be delivered in the same timescale for the same budget. Something has to give.

It’s OK to change the requirements but not OK to expect nothing else to change

In 30 years I’ve never worked on a project where the requirements didn’t change during the course of the project. This is why we use an Agile Development approach to most of our projects as it embraces the concept of changing requirements. The Agile Manifesto states:

 “We welcome changing requirements, even late in development. Agile processes are designed to harness change for the customer's competitive advantage.”

The issue arises when change is a one-sided conversation.

Here are four ways that change can be tackled:

1. The change is minor and has no material impact on the project and doesn’t affect the timescale or budget so the change can be included at no cost
2. The change is material and will impact the project costs and/or timeline. An equivalent piece of functionality is dropped from the requirements so the change can be included at no cost to the timeline and/or budget
3. The change is material and will impact the project budget and/or timeline. No equivalent piece of functionality will be dropped so the budget and/or timeline must change. This is the dreaded “scope creep” problem. The stable door has been opened and the project is now on a slippery slope to becoming a runaway project.
4. The change is material and will impact the project costs or timeline. No equivalent piece of functionality will be dropped and the budget and/or timeline must not change!

Points 1 & 2 above are generally predictable and are expected and embraced on Agile projects. This ensures that the right system gets built within the timeline/budget.

Point 3 is the norm on most projects and is an undesirable state, and normally avoidable, if you are committed to the budget/timeline.

Point 4 is the most dangerous of all. Incredible as it might seem this is a common position taken by inexperienced users/stakeholders.

Once you open the door to additional requirements with the brief that the budget and/or timeline shouldn’t change you have effectively lost control of the project. The project team will start to realise that the timeline is not achievable and morale will start to fall and people will be less productive.

And in case you’re thinking that you can easily add extra resources to the project to bring it in on time (but definitely not on budget) then consider my next point.

9 pregnant women won’t produce a baby in 1 month

A common misconception about software projects is that if you throw more people at the problem it will get done quicker. This is often a reaction to a runaway set of requirements.

In his book “The Mythical Man Month” Fred Brooks debunks this misconception. He states that “adding manpower to a late software project makes it later”. This is due to the complex nature of software development.

New workers on the project must first learn about the work that has preceded them; this learning requires diverting resources already working on the project, temporarily reducing their productivity while the new workers are not yet contributing meaningfully.

Each new worker also needs to integrate with a team composed of multiple developers who must educate the new worker in their area of expertise in the code base, day by day. The new worker may even have a negative contribution – for example, if they introduce bugs that move the project further from completion.

The communication overhead increases exponentially as the number of people in the team increases. In addition, as more people are added they spend more time trying to find out what everyone else is doing.

The bottom line is this – adding more people is not a panacea for an out-of-control project.

Flow is critical to success

For any project to meet its budget/timeline targets the project team needs to be able to maintain a smooth reliable rhythm of delivery throughout the project. Agile development methods refer to this as the “team velocity”.

To maintain this team velocity flow needs to be carefully managed. Flow refers to the friction or forces that are a drag on productivity and reduce team velocity.

Flow can cover all manner of things but as a stakeholder looking to have a project delivered on time here are some of the items that you will have to ensure are being managed:

• Have the right user representatives been selected and empowered to make decisions?
• Does the project team have easy access to the user representatives?
• Are the user representatives committed to being available at the right time so the team can capture requirements?
• Are decisions being made quickly without unnecessary delay?
• Are people turning up to scheduled meetings and not postponing them?
• Is the required infrastructure (desks, computers, software, servers etc) ready for the team?
• Does the user community understand that they have a commitment to do user acceptance testing on time?

Summary

Let me summarise by stating this – projects can be delivered on time and budget. I know this because I have been party to many projects that have met these criteria. However, successful projects don’t just happen by accident. To meet the dual aims of delivering projects on time and on budget requires a real commitment by all parties to these goals.

It may require a change in your processes to achieve this. It may require a change in attitudes to software development and the complexities involved. It will also require expectations to be carefully managed so that people don’t assume that material changes can be allowed without causing an impact.