There are few things as contentious as planning estimates.
My first experience at estimating a project was with my branch manager, in 1986, for a large project.
The funny part was- we did the modeling for the budget rightly, but the negotiation was mismanaged.
In the end… the final budget consumption was really close to our original estimates.
An impressive feat.
The next step, was to help keep under control a project that involved a couple of dozen of developers, working alongside the project manager.
What did I use? I developed a simple spreadsheet (at the time, it was Lotus 123- second half 1980s), with a table that I copied every week, keeping the opening figures of the week.
Really few formulas to compute the difference vs the speed of consumption of the budget, and allow to compute few other derivative numbers on how the budget was used and how we were faring vs the original plan.
Few years later, I was teaching project managers and business analysts the new software methodology that I had designed for their company- including planning and control.
The planning part is probably the most political issue.
As I discovered in my first planning experience, many managers in my company adopted a “contingency” increase.
Let s say that you decide that your level of confidence on the figures requires that you add a 20%- just in case.
There are different ways to manage this interval of confidence.
Chances are: if you add 20%, your interval is 40%- i.e. plus or minus 20%, but of course you demand a 20% reserve allocation.
If it seems huge- well, I will discuss in a future article how to manage the level of confidence.
Let s say that in most cases a -20%/+20% is politically unacceptable, and therefore is “buried”- either by “padding” figures, or by both padding a little bit, and hoping to have future activities to cover for it, if it will really be needed.
In my case, my approach was based on building a working prototype for a fixed price, and then use the knowledge acquired to reduce the interval to something more acceptable- say 5%.
And once you have you budget allocation, when you plan the use of the budget, then it begins the roller-coaster- control.
I will not discuss here project management tools (and I do not mean just software: the one between your ears is the most important tool to use).
But I found quite interesting that also people with a degree in mathematics are often ignoring that some basic mathematical skills can be used intuitively- and greatly simplify your life.
I was puzzled when I saw project managers taking a budget, splitting it across time and objects to realize across time, and then asking people: “how far are we?”.
And then, it was the wild west.
Does not matter if they are writing a document or a software- team members reply often to this question by seeing how much time they had been given, how much they already used, and then consider what the project manager would like to ear.
Some, highly optimistic, always report that they are ahead of schedule.
Others, highly conservative, always report that they are on time but there are some issues that could require a budget extension.
And so on.
However you collect the figures, I often observed an interesting focus on “where are we now”.
Also people with a degree in mathematics seem to forget some simple issues:
- the measuring points have to be relevant to the issue to measure: a program or document is either completed or not- before that, you can just say how much time you already spent writing it
- if you follow the “due date” or “milestone” approach, but everybody works 16 hours a day and you keep the delivery date, you are not on budget
- some project managers enjoy working from crisis to crisis- I wish them not to need the same team after the project ends; I received some of their exhausted staff once in a while…
- last but not least- “time” comes with different perspectives: speed, velocity, acceleration
It is basic high-school mathematics.
On the personal side, I am giving an example talking about applying these concepts to your own vacation budget.
Because, as in any project, also in vacation you will end up with something absorbing more resources than you expected it to do.
In most projects, moreover on fixed cost projects, there is this funny “pork barreling” attitude: everybody gets something from the budget.
And when I say project- everything with a defined purpose and set of deliverables is a project. And if it is not… it can be divided into projects: a political campaign, the launch of a new product, the writing of a document, and, yes, also a consulting or software project.
The main issue: it has to have a beginning and an end, and deliver something.
And once it is delivered… if what is delivered is used day-by-day, it is not a project anymore.
You have ten people in the office with nothing to do? Unless the project manager has real budget authority, (s)he will end up having more resources than (s)he needs at the beginning, when the budget is still unspent.
And will have to beg for (human and financial) resources later on.
I myself had to fight quite often with “people dumpers”- but my budget wasn t really mine…
The most appropriate allocation is of course having the budget associated with tasks, and people (with the right schedule and skills) at the right time.
And what about the three perspectives on time?
If you define a budget, say dividing your budget into a set of “packages” (time x resources x cost + etc = money) to be delivered at certain set dates, you are defining the speed of consumption of your budget.
But then, you have to monitor the velocity- are you keeping pace? Or spending faster than expected?
And finally, when you have a change in velocity vs. what you planned, it is accelerating? decelerating?
If you are ahead of time and below the expected budget consumption- check out, it means that you can build a reserve on the budget, but maybe something is left behind.
Unless you are really lucky- and things became simpler after you planned.
But do not worry: once a budget is allocated, as if by magic usually it is spent (more about this in a later article).
Therefore, do not organize parties or unplanned spending activities (like- free training sessions on how to sit up on your head) with this temporary budget surplus.
In my over 20 years of experience, in most cases going over budget is politically more acceptable that going under budget- therefore, something will often pop up to more than use the surplus.
But more often you will be late, above the planned budget- i.e. your velocity is higher than expected.
The first step is to understand not only that you are spending faster- but also if you are accelerating, and what to do to “decelerate”.
And as in physics- do not believe on Star Trek decelerating by braking out fast.
Otherwise, you will have the full weight of your project crushing you, and will take time to recover.
I mean: try to brake something in no space and time (your car, bike, whatever) and see what happens.
To control a slow down and get back, you have to manage the deceleration.
Moreover, you have to consider:
- why it happened
- what else needs to be fixed
- identify the new key measures to monitor
- reassess the resources in your team
In a future article, a small discussion on how to manage the most important part, that politicians and marketeers know quite well, but most other people forget: communication.
Believe it or not, but often issues can be solved- if you start talking and communicating before your risks become reality.
But wait when you are only the messenger of bad news… and you risk becoming the one that will leave the team.
Actually, this is a tactic used by some consulting companies.
Get a project and a budget with a plan- but before actually having enough information to develop a real plan.
Appoint a project manager, who will discover what would have been needed.
Pull the manager off the project, apologize with the customer, and appoint a second manager, who, with the information now available, will be able to deliver under the new schedule.
A twist on this requires a third project manager.
It happens when everybody believes that all the information needed is available.
The project starts as a walk in a park, and begins eventually to get off track.
Nobody knows why, and fixes follow counterfixes, until it is almost a mess.
And the project manager is “reallocated”.
The second project manager has just one real purpose: make the problems surface.
But, often, (s)he does not understand it (eventually, it will become second nature, to understand if you are the new project manager, or just the sacrificial lamb).
And once (s)he reports the issues, a third one steps in.
Why? To be the person who saved the day.
But without the second one, the third one would have been useless.
The funny part? If you are a company person, you will be asked in turn to play all the three roles- different customers, different projects.
Doing the “prototype” or “study first” approach is a more sensible solution- but requires negotiating.
Also because sometimes you do not have the option to do a test (e.g. in a political campaign), as the market will shift as soon as you will start your project.
Therefore, in some fixed-price projects, I did something simpler.
I converted the first steps into a “pre-validation” and “mapping” activity, while the team was working on items that would anyway be needed.
This allowed to identify along with the customer the real critical issues, and, moreover, build a working communication relationship before any issue had to be solved.
It is called goodwill.
And usually involves some give-and-take on what has to be delivered.
But too many otherwise good project managers spend too much time with Microsoft Project and Excel, and not enough with their team and their stakeholders.
How do you recognize them?
They are those that never write anything- and suddenly start producing minutes of every phone call, and spin meetings around.
Usually, when they feel that something is about to go wrong.
Thinking that nobody will understand what they are doing.
Start communicating early, and keep communicating.
Tags: change, communication, do, estimate, plan, project, recognize, you