I was reading some course material recently that was trying to teach people something to do with software development and it was using the same old tired “ATM machine” example. I’ve worked with hundreds of projects, many in the finance sector and none of them are anything like an ATM machine. One of the reasons that example is soooo tired is that it’s describing commoditised software development, it’s something I’d expect to buy off a shelf or go to a specialised vendor for. It’s not something I’d put my team of uber |33t haxorz on.
Developing software products is a balance between a creative and scientific pursuit, so it’s a little hard to describe, especially when that software can range from a tiny smartphone app, to a website, to router firmware, to an enterprise hr system (urgh!), to a big data processing system of systems etc. You get the gist.
The things these types of system have in common with each other is how different they are. And yet the traditional approach to managing these diverse kinds of work has been classical project management with a one size fits all process (I’m looking at Prince2, RUP, Iterative, Agile etc.) or worse hiring a large company full of body-shop project managers. For me this is one of the root causes behind large scale IT disasters.
I once had a discussion with the leader of a PMO in a large organisation of thousands of people about the nature of Project Management for software and he assured me that “someone who knows how to manage a bit of work can manage software, it’s just a different type of work” and indeed I should “stop thinking of software as special”. I’ve seen this attitude resonate in many organisations and is to me best summed up by the same Head of PMOs statement “from a project management point of view building software is the same as building a bridge”.
Now then. I know a little about software development, but not that much about bridge building (if you exclude my illustrious Lego engineer career when I was 7). If I managed the building of a bridge next door to one build by someone with a track record of bridge building who’s bridge would you drive your family on? Not mine if you’ve got any sense.
There are so many problems in the software development industry caused by people not understanding it and applying bad metaphors. When people who do understand it start to get the point across (e.g. the early agile movement) they often get misunderstood by the old guard who dress up their normal ways of working in new language.
Many of our “best” metaphors come from manufacturing lines where the same thing is made over and over again. That’s nothing like software.
To me a software project is more similar to making a movie than anything else:
- It’s a unique one off product (or a remake of a previous version) with new parts working together in new ways
- Once made we’ll often duplicate and digitally distribute
- It can cost a lot of money because it can be very complex and needs lots of specialist skills
- You need a high level plan for how you’re going to make it
- There’s no guarantee on return
- What’s written down originally bares little resemblance to the finished product
- We know when it’s good or bad but it’s hard to objectively quantify
- There’s lots of different types that need different collections of specialist skills
- Both involve people and time and so are subject to change, they have to be adaptive
- You can tell when the people making it had fun
- It’s not feasible that any team member can fit in any role
- There’s almost always going to be some quality problems
- You wouldn’t get a movie maker to build your bridge
- You wouldn’t get a bridge builder to make your movie
- You don’t make a movie faster by telling the actors to act faster
So, I don’t want a Project Managers that know how to work a gannt chart. I want movie producers that know how to work with a team holistically to get the best out of them both technically and artistically.
One of the figures often included on project reports, and present in many PM tools, is the EAC and EAC variance. EAC stands for “Estimated Cost at Completion” and is equal to the actual cost of work performed so far + the remaining estimate to complete. Expressed as a formula of confusing ‘initialisms‘ this means that EAC = ACWP + ETC.
For projects the EAC represents the total projected cost of the project. At the very beginning of a project when there hasn’t been any spend, the EAC is equal to the Estimate to Complete (ETC) and this is the first project baseline. As a project executes changes happen and projects may start over-spending or under-spending. In these case the EAC will start to vary from the baselined value as the actual costs + the remaining estimates are either up or down from the original baseline. This variance is expressed as EAC variance. A negative EAC variance indicates a project that looks like it is going to come in under the original budget baseline figure. A positive EAC variance indicates that a project is likely to overspend relative to the baseline figure.
EAC may be expressed as a financial figure or as an effort (in hours) value. EAC can also be combined with agile burnup measures across projects.