Skip to main content

Author: Harvey Kandola

Project Managers; The Enemy Within

They huddle in a corner, hunched over the Gantt chart you just handed out, muttering darkly. Only the occasional, quick glance in your direction betrays that you are the subject of their reproach. You sigh and for a moment are tempted to bat for your corner, but in the end you realize that it’s best to ignore them. A quick drink after work and they’ll come round. Instead, you scan through the list of Change Requests, Outstanding Issues, Bug Fixes and the Financial Summary and prepare yourself for your next meeting. This one ought not to be so bad, the client might not like what you have to say either but at least they don’t see you as the enemy within.

Who would be a project manager? There are times when it is akin to being a referee at a particularly fractious football match. You have to keep both sides apart while making sure that they play the same game and abide by the rules that they want to willfully ignore. Sometimes it feels as if only you realize the fundamental difference; this is not a game, and if one side loses then nobody wins!


We’ve all heard the story about the difference between what the customer wanted and what they got and we all know who has to manage the gap. What the team on both sides of the requirements/delivery divide should acknowledge is that this situation does not exist only as a comic creation, it exists as an inevitable outcome of the fact that requirements evolve from abstract needs but software developers can only build still life. If this was honestly stated by all parties right from the outset, then the first question that would be asked is who is going to make sure that we all walk away from this with a satisfactory outcome in the bag?  The notion of the project manager as the client’s mole or the supplier’s secret salesperson would evaporate.

One of the most irritating debates would also get put to bed; namely why the client should pay for project management. The client should pay because the project manager serves the project, not the client nor his or her direct employer, who only employs project managers because they have long experience and understand the necessity of project management. A project manager is a necessary part of the cost of delivery.

Fortunately we live in a world where the value of a good project manager can be proved beyond doubt. Provided he or she tracks everything related to the infamous ‘gap’; issues, changing requirements, moving timelines etc and stays on top of it, our project manager can walk into a meeting with the client or delivery team and the data at their command rams home their value to either side. Wait a minute, either side? Maybe Project Managers are the enemy within after all.

Don’t forget to leave your comments below

Harvey Kandola is a technologist and Certified PRINCE2 PM, currently leading CounterSoft, makers of Gemini Project Management software. He can be reached at [email protected].

Mind the Gap!

mindthegap1By It’s the age-old project manager’s nightmare; dodgy spec and a fixed-price project. Why doesn’t everyone accept that people will do their best and go for the flexibility and realism of Time & Materials (T&M)? These days there seems to be a strong leaning towards fixing the price of software development projects; after all, the budget is fixed so it doesn’t make sense not to fix the price as well. The trouble is, as many experienced PMs know, things are rarely that simple.

The issue is one of risk and who takes it. With a fixed price project the risk is deemed to be the supplier’s, with T&M it is the customer who takes the risk. This risk is presumed to be the risk of overrun. In other words if the project is not completed on time the cost of resources to continue working on it will be borne by one party or the other.

In the fixed price scenario, the supplier is in theory happy to accept the risk because it is the supplier who names the price and sets the timeline. If the project comes in early then the supplier makes a super profit because the engagement was profitable even if it was only on time, and the supplier is usually allowed to add a mark-up to the project for accepting fixed price risk in the first place. Everybody is happy unless the project comes in so late that it eats into the supplier’s contingency and extra margin, but if that should happen it is the supplier’s fault anyway for getting it so wrong in the first place. Or is it?

In reality the supplier rarely sets the price or the timeline. Customers don’t just sit back and accept the estimates they are given; they negotiate and they usually negotiate the fixed price risk factor away. Suppliers need the business and recognise that if they don’t do it their competitors will, so they take the risk of a fixed price project scoped out to meet exact deadlines. However, if they fail to meet those deadlines, they do not passively accept the cost of the overrun either. Even if it is entirely their fault, suppliers will do their utmost to stay in business, and running unprofitable projects is not a good way to remain solvent. They will under-deliver on what was promised, scale back on resources allocated to the project, either by using less or cheaper labour, and they will hit back with that dreaded weapon, the Change Request. When the arguments start over the Change Requests then nobody wins.

If we look at what was intended rather than the means of getting and paying for it we might be able to see a way out of the problem. Customers want good, reliable software that addresses a need that they have. However, suppliers cannot give customers what they want; they can only give them what they ask for. Customers, not being experts in the software development business frequently don’t know how to ask for what they want. Sometimes they do not even know if it is possible to get it. If you know that there is a gap between what the customer asks for and what they want, and you have enough experience to know that they rarely like what they are given first time, then the solution is to show them what they are going to get, early.

Project managers should try to minimize the size of the gap by making sure that, as far as possible, the customer sees what they are going to get as soon as possible, in small chunks. The sooner the “what you want” vs “what you get” battle is fought, the sooner the “risk” vs “pricing” issue gets resolved and the more likely the project is to succeed.

We call this “Minding the Gap” and we learnt to do this because the reality in large projects is that there is rarely only one gap. The need to “Manage the Gap” is just as great as the need to recognise it in the first place. Even Agile / SCRUM projects can fail if you fail to properly “Manage the Gap”.

Every issue represents a potential chasm for funds and resources to pour into and that is why Issue-tracking tools like Gem can be extremely beneficial to all parties concerned.

Don’t forget to leave your comments below

Harvey Kandola is a technologist and Certified PRINCE2 PM currently leading CounterSoft, makers of Gemini Project Management software.
He can be reached at [email protected]