19 December 2014

Software Development Expert

Paul Smyth - Kynetix Technology Group

5Posts 44,871Views 2Comments

Business Knowledge for IT

This community aims to provide links, resources, book suggestions, tips and insights to facilitate learning and development of IT professionals in financial services, and to develop a forum for IT professionals to exchange views on various related items.

So You Want Your Software On Time and On Budget?

03 October 2012  |  4024 views  |  2

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.

Comments: (2)

Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune | 04 October, 2012, 17:23

Great post! To your nearly-exhaustive list, let me add this one: 

Beware of Johnny-Come-Lately-Magicians who will attempt to hijack a project midway by claiming that they will deliver whatever functionality top management wants with no cost or time overruns. 

Commonly found on large and high-profile projects, such people are obviously promoting their personal agenda by currying favor with the top management. It's not always easy to sidestep them, but towing their line is quite often a receipe for disaster for the project.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Matt Scott - Wincor Nixdorf International GmbH - Bracknell | 06 October, 2012, 11:51 This should be mandatory reading for Project Executives, Programme Manager, Project Managers and Business Analysts. Great blog post! I have seen far too many projects fail or deliver late in the past due to poor discipline around Change Management.
Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Comment on this story (membership required)
Log in to receive notifications when someone posts a comment

Latest posts from Paul

7 Things Every CIO Should Know About Mobile App Development

04 December 2013  |  6536 views  |  5  |  Recommends 0 TagsMobile & onlineGroupBusiness Knowledge for IT

Why the 10,000 Hour Rule Matters in Software Development

22 November 2012  |  5106 views  |  1  |  Recommends 0 GroupBusiness Knowledge for IT

So You Want Your Software On Time and On Budget?

03 October 2012  |  4024 views  |  2  |  Recommends 0 GroupBusiness Knowledge for IT

Stop Wasting Money On Software You Don't Need!

10 September 2012  |  4289 views  |  3  |  Recommends 0 GroupBusiness Knowledge for IT

7 Reasons Why Software Development Is So Hard

08 August 2012  |  24917 views  |  6  |  Recommends 1 GroupBusiness Knowledge for IT

Paul's profile

job title CEO
location London
member since 2012
Summary profile See full profile »
CEO at Kynetix. Driving our best practice approach to software development.

Paul's expertise

What Paul reads
Paul writes about
Paul's blog archive
2013 (1)2012 (4)

Who is commenting on Paul's posts