Prioritising Time, Cost or Quality in Project Management

If you manage projects, or have worked on a project, chances are you’ll have come across the dilemma of time, cost and quality. More specifically, it’s the dilemma of which of those three is the priority.

For example, suppose you have a computer system that’s old and tired. It manages customer service interactions, and it’s important to your organisation that these are handled promptly and accurately. But is uses an out-dated architecture, and the expensive licensing contract with its supplier is coming up for renewal in 9 months, which will tie you in for another three years. The users of the system want some additional features in the system to support the greater variety of automated interactions that their customers are demanding.

The usual way to handle this is to do some analysis into options, and on the face of it (for this example anyway), there are two ways this can go.

• You can continue to use the existing system, perhaps upgrading to the latest release and trying to negotiate a cost reduction on the licensing while paying for development of those new features.
• You can go out to the market for a new system from another vendor.

A business case is drawn up and with 9 months before the existing system needs to be re-licensed, it supports replacing the system (not a surprise, given that users have become jaded about the existing system and have that yearning for a shiny new one that will give their customers a gold star service). A project is started up to manage the selection of a new system and its implementation and you get the call to manage it. You have a committed Sponsor plus a confirmed team of users, IT specialists and Business Analysts at your disposal. You even have the initial funding to define requirements and identify potential systems.

One of the Project Manager’s first tasks on taking on a project is to develop a Project Initiation Document – known in the trade as the “PID”. This document – briefly – sets out the project’s objectives, approach, timescales, risks, constraints and a bunch of other important information to ensure that the Sponsor, the Project Manager, and the team are on the same page. What it also needs to include is some understanding of the priority: time, cost or quality.

They’re all important. You want to achieve the objectives without overspending against the business case. You want the new system to be high quality because it supports interactions with your customers. And you need it to be implemented before the old system has to be relicensed. And in a perfect world, you’ll satisfy all three of these factors because everything runs smoothly throughout: no deviation from the original plan, no unexpected issues in testing, no pitfalls with migrating data from old to new, nobody leaves the team, and each night when you’ve left work for the day, the pixies will arrive and remove any potential obstacle from your project’s path. Yes, well-spotted: that was indeed sarcasm – because ALL projects encounter problems. As Mike Tyson once said “everyone has a plan, until you get punched in the face”.

So one of the early decisions to make on a project is which of these three elements is the priority: which one will you flex if (sorry, that should “when”) the project needs corrective action?

In the example I’ve given, the one that leaps out is Time. If you haven’t implemented by the time the contract for the existing system needs renewal, it’s going to have a massive cost implication. So, if it comes down to it when there are issues to sort out, you can either throw more money at the project, or tinker with the scope to make the work fit the timescale.

If however the project plan for the implementation is comfortably (for now) within the window, then because it’s a system that deals with customers, you might start off with Quality as the priority and getting the right quality may need more effort than you first thought, or (again) more money to pay for more functions or resources to help out.

And to complete the trio of examples, if your Sponsor has said that the budget is fixed with no room to add more, then all you can do is take more time (doing things more cheaply), or reduce the quality of the system you want to bring in.

The basic rule to bear in mind is that when it comes to Time, Cost and Quality, you can flex any two of them, but not all three. There is a fourth element which some projects may have to consider, which is Risk, but the same logic applies: you should still decide which of them is your priority and let the others flex if needed.

And, a final thought for you. Bear in mind that the priority may change during the project. At some point, the Finance team may says “enough is enough – no more money”, so Cost becomes your fixed point. Equally, if a five month project plan turns slowly into a 9 month project plan, the business case may now demand that Time doesn’t slip any further, and takes over as the fixed point from then on.

The Change Game

I run a small icebreaker at Project Management training courses called “The Change Game” to get everyone on their feet for a few minutes at the start of the day. Everyone stands up and pairs off. One of the pair turns around while the other changes three things about their appearance – loosening a tie, putting a watch from one wrist to the other – nothing too drastic (it’s a family-friendly course). The other of the pair then has to identify what those three changes were. You then reverse so that the changer becomes the guesser. And that’s it. Ten minutes of activity before we start the meaty part of the presentation.

Now if you’ve come across this, you’ll know what happens next. Everyone sits down and of their own accord puts their appearance back to how it was. The watch goes back on the original wrist, buttons are done up, ear-rings are put back in the ears. It’s inevitable, and it’s unconscious. This then allows me to make the point I wanted to make: change is uncomfortable; left alone, people revert to the way they’ve always done things and it has to be a conscious effort for most people to do things differently.

When you manage projects, you are orchestrating change. However big or small the change, you have to overcome a natural inertia among workforces and suppliers, attitudes and opinions. You may believe a change is good, but you have to convince others to agree – or have a clinching argument as to why they don’t have a choice – if you want their support for it.

The art of estimation on projects

So much rests on accurate estimating at the outset of a project. How much money do you need, how much time do you need from each resource, how long will it take. If you’re doing a Business Case, some of the information on it has to be educated guesswork. And to top it all, once you communicate a total value, or a date, even if it’s a guess, then many of your stakeholders expectations will have been set as they use that value as a benchmark against any revisions. Estimating is therefore a crucial skill.

Now there are many books on the subject, and almost as many recommended techniques to use. Many PMs I know have their own way of putting estimates together, but it will almost always involve breaking out the project into chunks as discrete as possible and then finding an expert in that area to give you his or her best guess. Take, say, testing: how much time do put aside for this when you haven’t yet got a full spec to work with? You could ask a Test Manager who’s worked in this area before. Give them the outline of the development, assure them you won’t hold them to any estimate, and then ask them for an effort / timescale range. You can of course ask several experts if you want and create your final range from the lowest and highest answers you get.

This is one of the most common “three point” techniques, because you can take the range and assume that you now have a best and worst case, so the true value is likely to be within that range. If you do this for every element you’ve broken the project into, you’ll have an upper and lower value for effort, cost etc. The next step is to work out a reasonable mid point to use in your final estimates. It’s here that a PM’s experience comes into play – did the expert get it right last time, or are they historically prone to pessimism (or optimism)? Then there’s the “lying weasel factor” (as Dilbert calls it). This is your gut feel about the veracity of the experts opinions, mixed in with your own feel about how many unknowns there are. The more you worry about these, the higher your estimates should be – perhaps even right at the worst case value.

Estimation goes hand in hand with planning: it’s best done when you’ve broken the objectives and deliverables into tasks small enough to be meaningful as pieces of work. As an example, my son will tell me his Maths homework should only take him 15 minutes. But he has 60 questions to do, so (I ask him) is it realistic that it will only take 15 seconds per question? Alternatively, if you have to estimate how long to tile a bathroom, work out first how many tiles you have to put up and then estimate based on how long to do 1 tile (or 10) and scale up (then add in time to have tea breaks or arguments with the wife).

If you’re going to use estimates on key documents like the Business Case, then my advice would be to document how you came up with the estimates, don’t be afraid to add contingency, but justify it – this is new technology so we’ve taken that into account, or we’re doing the work over the holiday period so it’ll take longer because of resources taking time off – and so on.

In the end, estimating is just educated guesswork: as a PM, all you can really do is try and make them as educated as possible.

What does a Project Manager do?

A Project Manager is simply a person accountable for the delivery of a Project. If a project is about introducing change, a Project Manager manages the work necessary to make that change happen. In general that means a Project Manager will:-

• Understand the activities needed to make the change happen
• Organise a team to carry out those activities
• Control progress, status, and any factors that could get in the way
• Keep stakeholders informed and happy

In the main, bearing in mind that every project is different, the sort of key skills and behaviours a PM typically needs would be:

• Excellent communication ability
• The ability to create and motivate a team
• The ability to influence without authority (often, a project team is created that does not report in a line sense to the PM. As team members have other masters to satisfy, the PM needs to be able to secure their attention on the project work)
• Organising and planning focus
• Flexibility (methods that work for some projects and team members may not work on the next project you do. Also bear in mind that things change, including objectives, budgets and timeframes)
• One eye always on the objective – that is after all why the project exists

So, in my experience, the types of tasks a PM needs to do include:-

o  Keep track of project finances	o  Negotiate with suppliers
o  Manage teams and their assigned work	o  Communicate up, down and sideways
o  Chase up for progress on tasks	o  Identify and manage stakeholders
o  Organise, run and minute meetings	o  Provide progress reports
o  Write, review and approve documents	o  Manage change requests
o  Create project plans	o  Manage resource plans
o  Update project plans	o  Manage document versions
o  Ensure quality	o  Manage document storage
o  Log and manage risks	o  Organise support hand-offs
o  Deal with issues and remove obstacles	o  Ensure quality of deliverables
o  Check assumptions	o  Organise post-project celebrations
o  Manage dependencies	o  Leap tall buildings in a single bound

That is not an exhaustive list of course. The last one is optional, especially if you don’t have a cape!

What is a Project?

Ask 10 people this question, and you’ll get a variety of answers and they’ll all probably contain one or more of the right elements. Just as a “car” is a vehicle to transport from A to B, a “project” is a vehicle to deliver a change. Cars come in all sorts of shapes and colours and with a range of different features. So do Projects.

Prince2, the UK Project Management methodology, defines a Project as “A management environment created for the purpose of delivering one or more business products according to a specified Business Case”.

Translated into English, I’d put it this way: “A piece of planned work or an activity which is finished over a period of time and intended to achieve a particular aim to an agreed quality and budget”. The emboldened words are the key ones.

Planned work : successful Projects don’t just “happen”; they are planned and managed with the knowledge of, and in the face of, the many potential and actual obstacles that will derail it if the Project Manager and their team is not keeping an eye on it.

Period of time : a project has a start point, and an end point.

Particular aim : The reason a project exists is to deliver a required change, whether that change is to put something new in place, to improve on something that already exists, or to stop doing something. In business terms this is the “objective”, and when this is met, the project can stop.

Agreed quality and budget : Someone, somewhere, has requested the change that the project is there to deliver. That person – of group – defines what good looks like and how much the project will spend.

Projects are all about introducing change and with that in mind, examples of work that could be a Project include:-

• Building a new hotel (but not day-to-day running of it)
• Creating a Proposal document (which, if accepted could mean the project is extended to deliver it)
• Replacing or upgrading a company’s reservation system
• Upgrading software on all of a company’s laptops (but is only a project if done within a specific timeframe)

In fact, based on the criteria above, even getting married can be a project (in my case managed by my wife and her mother) because you have a timeframe, a plan, an objective, and a budget.

Project Change Management

Time for another overview of one aspect of Project Management. When you manage a project, unless it’s a very small project, or a very quick one, you’ll need to be have a procedure for Change Management. At its heart, this is simply the way you will deal with any requests to change any of the baselines against which you’re operating. A “baseline” by the way is simply an agreed and known point against which you can make comparisons, so for example, you can baseline a document so that if it gets amended, you can see where the amendments are.

So that’s the first rule of Change Management for you: define your project baselines. These should apply to key elements: scope, cost, time, quality, benefits. Each of these elements are linked: what you need to deliver (scope) affects how much it costs, how long it takes, what you need to do to ensure it is fit for purpose (quality). Ultimately, all of these will drive the benefit you get out of it at the end.

Once you’ve baselined these elements, the next rung in your Change Management process is going to be detecting potential changes to those baselines. Anyone can come up with potential changes and here are a few examples:-

• a supplier says the cost has to go up because raw materials are more expensive
• a team member points out that the project plan has missed off a number of team holidays
• a business user suggests a new requirement which will improve the end product
• the sponsor wants an extra level of rigour in the testing to ensure a higher standard of quality
• the company wants to release the product earlier to market than was first envisaged

The standard process of Change Management consists of:-

1. Track – log any potential changes that come up. This applies even to changes needed because something has been forgotten in the baselines: even if accepting it is going to be a no-brainer, still record it in the list. Any new entries get assigned an owner to do the Assess step. Keep the list updated as the change progresses through to a decision.
2. Assess – work out the impact to your project baselines if the change were to be included (or conversely, if it were not included). You’re looking here to understand whether you’d need more time, more money, whether you have to change a specification or even a Business Case. This stage also includes making recommendations about the course of action for the change item – whether to propose accepting it, whether you suggest dropping some other scope element to include it without extra cost for example.
3. Make your mind up – there is no potential change, ever, which is accepted without a decision. Who makes the decision will depend on the impact. If your baselines don’t change (if Bill moves his holiday on 1^st August to start on 8^th August and there are no dependencies on this) then the PM can agree to make the change. However, in the majority of cases, it’ll be for your Project Sponsor and Project Board to decide whether the change is included or not. You need to arm them with all the information they’ll need to make that decision such as impact on cost or time.
4. Execute once you have the decision, off you go. This means updating your project’s baselines – updating documents, perhaps submitting a request for extra finance, adjusting plans to take the change into account and so on. Or, if the change is rejected, simply update the tracking and forget about it. If anyone else ever says “why didn’t we do…” your tracking is your historical record.

There are two important footnotes to the above. Firstly, there’s an insidious little term called “Scope Creep” to be wary of. This is where the scope gets added to almost imperceptibly with little extras and OSINTOTS (a PM acronym for “oh sh*t, I never thought of that”) in such a way that when you step back later you see that the cumulative effect of these tiny changes has a stressed your baselines to breaking point.

Secondly, keep in mind that your objective is to deliver the agreed project. I have worked on projects where the volume of Change Requests coming in was so huge that the PM was allocating a sizeable (and inappropriate) amount of his team’s time to assessing them, to the detriment of them working on the deliverables that were actually in the scope. So remember that every potential change is a distraction until a decision is made to include it. However, you can’t just ignore change: every worthwhile project has potential changes (as Von Moltke said: “no plan survives contact with the enemy”), so factor the time to manage them into your planning of the team’s workloads.

There you go. Change Management in a nutshell. Good luck.

Project Management: CRAID

Unless you are managing a very simple project, from the moment you start it, to the moment you close it, there will arise uncertainties – the real world does not let you manage in peace. The standard technique used to manage uncertainty across the life of a project is called RAID Management. This is an acronym of course and stands for Risks, Assumptions, Issues and Dependencies. I also add a C for Changes at the front, hence CRAID. It can be a complex subject, but this is where the skill and experience of a PM can really pay dividends. I offer you then a few key pointers about how to TAME uncertainty.

Changes will arise in a project. Someone wants the data flow to work differently than first envisaged, your sponsor wants to add in a feature to make the end result better. Changes require attention and an analysis of their impact on the project baselines – time, cost, benefits and resources.

1. Track: anyone can come up with a change request: when they do, log it in a list, record it’s status and the decision that is made against it.
2. Assess: spend a reasonable amount of time to work out the impact of the change – how does it affect the project timelines if we include it? is it worth doing?
3. Make your mind up: based on the analysis, decide whether to include the change in the project or not – the decision should always come from the Project Board.
4. Execute: add the change – if approved – to any documents, work schedules, plans, tests etc.

Risks are defined as circumstances that might happen and that if they do, will affect your project baselines, whether positively or negatively (its usually negative).

1. Track: get you, your team and your Project Board to think of anything that could go wrong. Log all they come up with in a list and record against each entry what you do about it and what the status is. Also, make sure every entry has an owner.
2. Assess: work out what each risk can do if it materialises: a standard way is to consider on a scale of 1 (trivial) to 5 (almost certain) how likely it is to occur, and what the impact is if it does. The higher-rated items are what you focus on first.
3. Mitigate: think about how to deal with the risk and prevent it impacting you. Can you reduce its effects, put a contingency plan together, transfer some of the risk to someone else, avoid it altogether by doing something different? Just remember that denial is not an option! Give the Project Board regular sight of these actions.
4. Evaluate: keep an eye on the risks in your log (add new ones if necessary) and update your mitigation plans accordingly if things change.

Assumptions are tricky, but they are things you think you can rely on that need to be checked. You get a lot of these at the start of a project, but if you’re doing your job as a PM correctly, they should dwindle to almost nothing once you start creating the deliverables.

1. Track: log them all and give each an owner so you can capture and update status.
2. Assess: check out each assumption to verify it and work out the impact if you’re wrong in your assumption. Where you can’t verify it, can you reduce the impact for example? Log the checking actions you give to team members.
3. Monitor: As with other uncertainties, keep an eye on them so you can react if things start getting more serious.
4. End: the aim is to reduce assumptions so you can forget about them: take every opportunity to close them off, or prevent them hanging over your project.

Issues are basically what happens when risks materialise or when things just go wrong that you didn’t expect. They are right in front of you and may need immediate action, so this is where problem-solving skills can be useful.

1. Track: log the issue so you can track actions and status. Assign it to an owner who will keep you informed about the activity on it.
2. Assess: work out how serious the issue is and what impact it has on the project in terms of cost , time, resource etc. Also evaluate how quickly you need to deal with it – some issues can be left until later and may resolve themselves on their own, and some may have too little impact to be overly concerned.
3. Monitor: agree actions to deal with the issues and bear in mind that some actions create Changes, or other Risks to be recorded as well.
4. Execute: get the actions done.

Dependencies are a special type of uncertainty that you have less control over because they’re in the hands of other people or projects.

1. Track: you see the common theme yes! Log the dependencies and assign an owner among your project team to look after them.
2. Assess: for each dependency, work out who’s doing what to keep an eye on it. If it’s a dependency on a supplier, who owns the relationship with them and how are they going to keep the supplier in line for example?
3. Monitor: keep an eye on the dependencies for anything which might have an adverse impact on the project – you could also add contingencies into plans to cope with any delays for example.
4. End: as with assumptions, the aim is to reduce dependencies so you can forget about them: take every opportunity to close them off, or prevent them hanging over your project.

Project start-up: a bit of advice

I find it energising to start a new project. As a Project Manager, my job is to take a brief (and it’s no surprise it’s called “brief” given the lack of detail in many of the ones I get) and facilitate turning it into reality. Change is exciting, and projects create change. Each project comes with its own new team, new stakeholders, all of them looking to you to make this change happen successfully. And each project is a new chance to make a first impression. How I start a project then has always been for me a crucial step in the road to delivering it.

So when a “brief” lands on my desk, the first thing I do – apart from reading it – is ask a lot of questions, like these:

• What change am I delivering (what’s my objective)?
• Who owns the Business Case (who’s my sponsor)?
• How much money do I have to do it (what’s the budget)?
• What timescales do we have to work with (what deadlines are there)?
• What does “good” look like (what are the quality criteria)?
• Who is going to work on the project, and for how much or their time (what are the resources)?
• Have we done anything like this before (what lessons can we learn from past projects)?

Now the answers to these may not be complete at this stage, but whatever I can get goes into a “Project Start-Up Document” that I use.

The Project Start-up is my record of what I’ve been told in the Brief and in meetings, conversations etc. I’ll record any setup or finance codes, names of people I’ve spoken to, discussions that bear on the project, any work done to date prior to my being involved. I also record what I plan to do next. And, to make sure I’ve understood things correctly, I’ll ask my boss and my project sponsor to signoff this document – or tell me where it’s wrong.

Next up is the kick-off. Most companies will have a raft of departments and business areas that have to be represented on projects, so I work through a list of standard project roles and responsibilities and work out who is going to be involved to fill the roles, and who will represent their business areas as stakeholders. Where I can’t get a name, I’ll use the head of that business area as my contact point for now. All the names I come up with get invited to a Kick-Off meeting. The meeting has an agenda, and I’ll send out the Startup document beforehand to all I’ve invited. Some won’t attend of course, but everyone invited gets a copy of the updated Start-up Document after the meet so they know about it.

And finally, before everything gets going for real, there’s the Project Initiation Document (or PID). It’s a Prince2 term and to me is the most important document a PM can have. A well-written PID will contain the objectives, scope, constraints, risks, assumptions and dependencies, planned milestones, roles and responsibilities, project organisation structure and critical success factors. It’s my contract with the Project Board to demonstrate I know what they want me to deliver, and against which the project’s success will be judged. This living document, updated throughout the project where necessary is key to ensuring the Project Board has confidence in the project and that I am comfortable with their expectations.

After that, you just get on with all the easy stuff like bringing a team together and delivering!

Top 5 key skills a Project Manager needs?

 I haven’t done any writing in relation to work for a while, so here’s a view on Project manager skills. Project Managers come in all shapes and sizes, but whatever the field in which a PM plies his or her trade, there are some basic skills that all of us need to make a success of the projects handed to us. I could list dozens, but here is my own view – today – on what the top five is.

I know readers will have different views, so why not share your top 5 and we might be able to come up with a definitive list.

Communication

First and foremost of the key skills is the ability to communicate to all levels of stakeholders in a way they understand. Whether a phone call, an email or a face-to-face talk, whether the communication is a status briefing for the Project Board or a request for someone to carry out a task, every communication has a purpose, and is intended to achieve a specific result. Approach every communication by knowing what and why you are communicating. By tailoring that communication to the audience in a way they will understand, you are more likely to get the result you you need.

Preparation and Planning

This skill isn’t just about putting a project plan together. German strategist Von Moltke said “no plan survives contact with the enemy”, and in project terms, this means that the most perfect plan for delivery will be affected by events as it progresses. So the skill covers anticipating what could go wrong and removing roadblocks before they are in front of you. It also means being prepared properly for meetings – as Sir Humphrey in “Yes Minister” would have it, the best minutes for meetings are written in advance.

Stakeholder management

A Project Manager has to deal with a multitude of motives and perceptions from the variety of stakeholder involved in a project. Business stakeholders want their change delivered to specification on time. Financial stakeholders want it delivered within budget. Supplier stakeholders want clear requirements. Team stakeholders need to know what they should do by when. Understanding these different viewpoints is key to managing them, because if you get it wrong, then the effort dealing with the misunderstanding can be demoralisingly high. A PM has to be a combination of press officer, negotiator, diplomat and counsellor, and know what  makes each stakeholder tick.

Problem solving

Not a skill you’d usually see mentioned in relation to Project Management, but I feel this is a crucial skill to have. In twenty-odd years of project management, I can’t recall a single project which didn’t have some problem come up that needed to be resolved – and yes, I mean “problem” and not “opportunity”. Even after you’ve done the risk analysis, prepared for every meeting and got your stakeholders onside, something will come up that wasn’t anticipated. This skill is in part being able to solve the problems that come up, but it also applies to knowing who to approach to get a problem solved. Having the ability to sort these problems out quickly breeds confidence in your team. 

Financial management

All change comes at a cost, whether it’s in resources, time, equipment or simply money. It’s rare for me to be given a project that doesn’t come with a budget, and whether I’ve had influence over the setting of that budget or not, I am expected to manage the project within that budget. At any moment in time, I could get a request from the Finance teams to state what I’ve spent (Actuals), what liability I’ve created for the company (Commitment) and what the project cost will be in future months or at the end of the project (Forecast). If I don’t have this information immediately available, it can take up valuable time to prepare it, and these requests are often (in our company anyway) urgent. I keep the finances up to date as the information comes in, and track it in a prepared spreadsheet which anticipates the information requests I will get. Knowing what the accurate financial status is on my projects, and importantly, being able to share it immediately, gives my stakeholders confidence.

Appraising a Project Manager

A light-hearted one to start with. I can’t take the credit for creating all of this, but it’s definitely something to share!

PM Appraisal Guidelines