Finding out what’s best …
Just doing our best ain’t good enough – we need to be more savvy than that and work out precisely what’s the best thing to do first. So far, we’ve identified the conflict, and we now need to assess possible solutions.
If you haven’t read It’s not rocket science yet, please do first, as this article is a continuation of that theme.
I’ve said that key to a successful project is not just having everyone involved do their best, but having them work out what is the best thing to do, and then do their best at that. Anything else is at best a waste of effort, and at worst will doom a project.
I’ve also said that a sucessful project, just as any other system, needs a systemic view, rather than a bunch of local team views (new business, project management, creatives, developers, etc.).
So, how on earth do we go about finding out what’s best from a systemic perspective? A good place to start may be looking at some of the gripes that sit uncomfortably between teams involved in a project.
For example:
Project Manager (PM): developers’ estimates are always wrong.
Developer: PMs treat our estimates as promises, and thus can’t handle it when they turn out to be inaccurate.
Let’s think about lines on a graph: x axis denotes time; y axis denotes understanding. At the very start of the project, my understanding of what’s involved is minimal. At the end of the project, I know all there is to know about it (ah, the beauty of hindsight!). Between those two points, the line rises in a sloping curve, with most altitude gained in the first half of the project.
Where does estimation take place? Early on in the project, where understanding is incomplete (often requirements are incomplete too).
And that’s only the first problem. Here’s a second: when we estimate towards the start of a project for the length of a project, we’re looking far ahead into the future. The further we peer, the poorer our seeing, and the harder it is to a provide realistic estimate.
Estimating a project from the start requires long-distance lenses, so we may pad with a buffer because that protects us slightly. But, as the project progresses, problems arise, change requests come through, and the specification that we’ve been working from changes (or it doesn’t, even though the functionality does, but that’s another problem). This is how reality departs from our estimates. Towards the end of the project, we’re dealing with bugs that we couldn’t foresee and test results have come in, which frequently mean lots of change requests now that the client’s seen the proposed release version.
Two problems: estimating when our knowledge about the project is less than complete; changes arising that throw the project off schedule. Now what could solve them?
We want our estimates to be more accurate, so they can be considered commitments; and we want to be able to handle changes and problems that arise.
Imagine that, as a developer, you were asked each morning how long it would take to perform the single task you were about to tackle. Your response would be in hours, and probably more or less accurate. Imagine now, that you were given the whole list of tasks up front and asked to estimate on them – the answer would be in days, and a lot less accurate.
Firstly, say it takes 10 hours to complete a task, and you’re 10% out: it takes 11 hours. We’ve lost an hour. Say it takes 10 days, with the same margin of error, and it’s taken 11 days. Say it takes 100 days, and it’s taken 110 days. Thus the same margin of error, when affecting differing timescales, has very different ramifications. And just in case you think I’m being unfair by swapping from hours to days: if you think something will take one hour and I think it’ll take two, we have room for a discussion – the difference is clear; if you think something will take 30 hours and I think it’ll take 31, it’s a lot harder to explain the difference and decide which is a better estimate.
If we can make our estimates more often and more short-sighted, rather than a single one tackling the whole project, we stand a much better chance of getting the estimates right, we can adjust them based on recent learnings, and we can incorporate changes/problems as they arise.
That may resolve the conflict of PMs wanting commitments and developers not having concrete specs to work from (with no changes, ever ever). Whaddya think?
Tags: cloud, management, pipeline, process
management, process | jamesk, May 14, 2008 9:20 pm
Tim — June 18, 2008 @ 12:30 pm
You are of course completely right, but choose to ignore one rather fundamental problem, the way the client approaches the business of development
The ‘average’ marketing client is used to agreeing how much it will cost to get a particular thing done. They structure their business around it. Indeed, the entire business works from a yearly planning cycle that goes something along the lines of:
1. Define objectives for year
2. Work out activities to do them
3. Estimate cost of activities
4. Submit budget to board for approval
5. Start specifying
The client approaches an agency (or multiple if it is a pitch), with the work scope, the budget, the expectation, etc already set. Sooner or later (depending on agency structure) a Project Manager is introduced who’s job is to deliver the expectation, for the budget of the scope, and they haven’t even done the scoping part yet! So, the PM passes those same problems down the line.
While, given the budget, the PM would end up with a better result for the client using the approach you suggest, the problem is that they haven’t been setup by the agency or the client to do that. And most digital agencies are trying to get their clients to understand digital, let alone explain to them that the entire way they approach it is flawed. And it would take a very ballsy PM indeed tackle that problem as they would be having to change the attitude of the client, the agency and the way they conduct business with each other.
So spare a thought for your poor PM, it’s not their fault! (Although, they could take the risk on personally, run the expectations of the client waterfall, use an agile approach with the internal team and know the end result would be fantastic. But that is a huge leap and puts that persons job on the line if there isn’t buy in to the approach from senior management. Which we can assume their isn’t due to things being the way I said they are in previous paragraphs!).
jamesk — June 18, 2008 @ 1:01 pm
@Tim, I’m not blaming PMs – I completely agree that they are caught in this system as much as anyone else.
Yes, I have ignored the client’s expectations here, but I do believe that it is possible to address the way we work with clients, even if that means we lose some.
I think your list of the client’s planning cycle is as good a place to start as any: isn’t that just another waterfall process?
I wonder whether it’s possible to have a cost overview for a year which has next to nothing to do with the reality, and within that overview, projects can be identified and scope/estimates worked out on an ongoing basis. For example, doesn’t a client have an annual budget, which he then gets to spend on projects of his choice which maximise his return? No one will hold him to ransom if he spends his budget and delivers, but the way he’s done it is different to his plan. Or am I being naive?