≡ Menu

5 Tips for making better decisions every day

Ben Ferris

Ben Ferris

This is a guest post by Ben Ferris.

The decisions you make every single day on your projects will greatly affect the eventual outcome of them. This means that if you can learn to make better decisions then you should expect to run more successful projects. It sounds really simple and to be honest most of the best tips I have come across are pretty straightforward once you think about them.

1. Give yourself time

Making a decision under a lot of time pressure is one of the surest ways of getting it wrong. I think it is safe to say that most of us think better when we have a few minutes of peace and quiet to consider the facts. In fact, a lot of the time you will come to a better decision if you sleep on the matter before giving your opinion. There are very few situations you will come across in your project management career where you will need to make a snap decision without being able to think it over. You should therefore avoid rushing into your decisions and instead take your time to get them right instead of simply getting them out of the way quickly.

2. Get all the facts

Another common mistake made by under pressure project managers is to make their decisions without being aware of all of the facts. If you do this then the only way you can expect to get the right conclusion is through sheer luck. Probably the most important step in your decision making process is that of doing your fact finding and working out what it is all about. This is a part of the process which it is easy to rush past but if you want to get it right then you will want to spend sufficient time on this stage before you even start to consider what your options are for the final decision. You might even find that once you have all of the facts the decision becomes a lot easier than you thought it was going to be.

3. Think of the consequences

One of the other points which it is easy to overlook is that of the consequences of your decision. For example, will it lead to you needing more budget or more team members or will it result in a change to the project plan? There are often a number of different follow-on effects to consider before you go ahead and act on your decision. You might need to organize a workshop or at least seek the expert opinions of others before you can safely state what the consequences of your decision could be.

4. Seek other opinions

The last point mentioned looking for other opinions and this is something worth bearing in mind in other circumstances as well. What can sometimes happen is that you end up being too close to the project and therefore can’t see the wood for the trees. If you go and get the opinion of someone who is a bit more distant from the piece of work then you might be surprised by the different perspective they can offer you. If you are very lucky you might find that you work close to someone who is an excellent sounding board and who can give you the advice you need at the right times. I used to work beside someone who met this description and he made my life a whole lot easier. Best of all, he never imposed his opinions on me or got involved without being asked. He just sat there listening to what was going on around him and then gave me some wise words whenever I asked him for advice.

5. Be flexible

Not every decision you need to make will require the same thought process, so you need to be sure to adopt a flexible approach which allows you to adapt your ideas to the situation. The project management world is one which requires you to be flexible anyway so you should soon get into the habit of being flexible. You should approach each decision in the way which best suits it. Personally I like to make out a list of the strengths and weaknesses of each potential decision but I know that this isn’t necessarily the best approach in every single case. Being flexible is all about knowing that you have the skills and experience to weigh up the situation and choose the right way forward even if it is completely different from the way you have done things in the past.

About the author: Ben Ferris has over a decade of project management experience and is the founder of Cobalt Project Manager, a web-based project management solution that helps teams successfully plan and manage projects. Read more on the Cobalt Project Manager Blog.

7 comments

Overcoming bias in project management

Roland Hoffman

Roland Hoffman

This is a guest post by Roland Hoffmann.

A project manager is the lynchpin of a successful project. Her leadership and guidance is of paramount importance during planning and execution. Since good decision-making is critical for good leadership and guidance, project managers need to know how heuristics (mental disposition) and biases (personal inclinations) influence a project manager’s decisions. Therefore, effective project management training addresses these natural human variables to enhance traditional project management science.

Three types of heuristics

Heuristics are natural cognitive functions with risky implications for project managers. What appears as common sense is actually irrational decision-making, which can happen daily in a project manager’s life and limit her success. There are three types of heuristics.

Anchoring occurs when a project manager adjusts an estimate closer to a number she previously heard or saw. For example, she may not schedule the necessary two months for a task because the technician said, “Two weeks should do it!” Even if the project manager disbelieves the two-week estimate, she would be unlikely to stick to her two-month plan. If the technician had said, “We will need at least four months”, the project manager would likely schedule more than two months.

The availability heuristic is another irrational intuition, which implies that easily remembered information is most important. For example, if the project manager saw a car crash in the morning, she may later decide to pay for better insurance coverage for her team, even though the statistical likelihood of a car crash has not changed.

Finally, the representativeness heuristic can also affect projects. This occurs when people use representative association rather than factual analysis. For example, a project manager may not hire a genius who interviewed in a hoody, because she often sees a group of skateboarders in hoodies playing during working hours. The hoody unconsciously represents bad work habits, leading the project manager to not hire the candidate, even though she would have hired the candidate, if she only evaluated the candidate’s test results and qualifications.

More types of bias

Beyond these heuristics problems, project managers should learn to recognize framing, confirmation, and belief biases. A framing bias skews analytical objectivity. Another well-known experiment asked subjects to choose between saving 200 of 600 patients or losing two-thirds of the 600 patients. Naturally, almost everyone saved the 200 patients – even though the choices are mathematically identical. This bias may cause a project manager to under-charge a change because the sponsor framed the request accordingly.

A project manager with a doctorate may ignore the excellent advice of a laborer if she believes that college education is a prerequisite for good advice

Second, the confirmation bias prompts people to agree with evidence that confirms their prior decisions. For example, a smoker may trust statistically irrelevant studies that conclude that cigarettes are not harmful. A project manager with a confirmation bias could use a questionable report to justify polluting the environment, since she actually only wants confirmation that the containment cost she missed in her budget is unnecessary.

Third, a project manager should heed the belief bias. It distorts reality with long-standing beliefs that act as powerful, silent motivators. For instance, a project manager with a doctorate may ignore the excellent advice of a laborer if she believes that college education is a prerequisite for good advice, or a superstitious project manager may delay the project’s completion to avoid acceptance on Friday the 13th.

Mitigating against these challenges

Humans are normally unaware of biases and heuristics, and awareness requires training, skill, and experience. Project managers are particularly susceptible to consequences, because projects must succeed the first time and offer limited learning opportunity that does not end in failure.

Role play can help. For example, a trainer could assign stakeholder roles and secret objectives to students on a project management course who then complete a tense price negotiation. Afterwards, in a second exercise, students conduct a rigorous stakeholder analysis mitigates and realize that the tension was the result of anchoring heuristics.

To give another example, the project management trainer could demonstrate the framing bias with a procurement drill that has different pricing anchors, or discuss the duration variances from two distinctly-framed schedule instructions. This would convey formal procurement practices and schedule management concepts, but also exemplify the results of human nature. The result would instantly create experience and benefit real-world project scenarios.

Ultimately, project managers must learn how heuristics and biases can affect decisions through experience. The goal is not a project manager who questions every action and decision, but one who makes critical decisions with the use of due diligence to avoid human shortcomings. The performance improvements will bring real benefits to the individual and the organization.

About the author: Roland Hoffmann, who founded Hoffmann Conseho in 2007, has spent 20 years leading projects in technology, construction, marketing, operations and finance. His specialty is high-risk projects, where he prevents failure or helps projects to recover from failure. He has led project teams with over 70 people on four continents, has experienced spectacular successes and remarkable failures, and gleaned invaluable knowledge from each.

1 comment

Project Pain RelieverThis is an extract from Project Pain Reliever. I contributed two chapters and they are being serialised here over a month. Last week’s extract was about the issues and warning signs related to constantly changing requirements. If you find yourself in a similar situation, here’s what you can do about it.

What should I do?

When the requirements keep changing, it’s important to nail them down as quickly as possible to get back on track.  Establish where you are now and how you will handle changes when something else changes – because it will!

Clear set of requirements

Go back to your scope document.  What is this project trying to achieve?  This forms the underpinning structure of your requirements.  List all the requirements you currently have on the project and make sure they all tie back to the project’s objectives.

Ask all your stakeholders to review the list and confirm that it presents the current view of what they want the project to deliver.  If there are conflicting requirements – Marketing want the widget in blue and Customer Services want it to be orange – ask your Sponsor to arbitrate.  It might be easier to get everyone in the same room to agree the final list, although if you expect there will be some conflicts you could organise individual sessions with each of your stakeholders in the first instance.

This exercise will give you a baseline for the project’s requirements.  Any changes after this need to be assessed and taken through the change control process.

Set expectations

As part of talking to all the project’s stakeholders about their requirements and the definitive list, take the time to explain to them that there is always a cost associated with making a change.  If they change their minds in the future and want to add or modify a requirement, there will be a price to pay.  It’s not always a financial price.  As a result of the change:

  • The project could take longer or finish earlier.
  • More resources could be required.
  • The result could be a different quality outcome to what was previously agreed.
  • The project could cost more.

Changes can be desirable, so stakeholders should know that they do have the option to make changes if required.  However, they should do so in the full knowledge of what the impact should be, and with guidance from you about how possible it is to make the change.  For example, it is far easier to accommodate changes early in the project.  If you are building a hotel, it is not going to be easy to change the layout of all the bedrooms when the decorators are just finishing up.  Any smaller changes that cannot be accommodated now could be packaged up into a Phase 2 or another project in the future.

Change control process

Now you have a baseline of project requirements, you need to know what to do should you be asked to make another change.  A change control process informs how requests are handled for new requirements, or modifications to existing requirements.  You may have a formal change management process, or you may choose something less formal – either way, the steps to go through are the same:

  1. A request to make a change to the baselined requirements is received.
  2. The change is assessed against set criteria, typically the impact on:
  • The schedule
  • Resources
  • Other requirements
  • The budget
  • Project risks
  • The objectives and project as a whole if the change is not done.
  1. A decision is taken whether to implement the change or not:
  • If yes, document the change, update the plans and schedule and let everyone know.
  • If no, tell the person who requested the change that the work will not be done, and the reasons why.
RFC process

A request for change process

Make sure that project stakeholders and in particular, your Sponsor, understand and agree to the change control process that you will be using from now on.

You know you’re in a good place when…

You know you’re in a good place when:

  • You have a clear set of requirements to act as a baseline.
  • Everyone understands what making changes to these means.
  • Everyone understands how changes can impact the project.
  • You have a process in place for controlling change on the project.

Changes to requirements happen – you just have to be prepared for them when they do.

Project Pain Reliever, edited by Dave Garrett, is published by J. Ross and is available on Amazon.co.uk and Amazon.com.

1 comment

Project Pain RelieverThis is an extract from Project Pain Reliever. I contributed two chapters and they are being serialised here over a month. The last two extracts looked at producing a realistic schedule by involving the team in the planning. Read about the issues and warning signs here, and how to create a collaborative plan here.

Today’s extract is the first part of the chapter about requirements management.

Everything changes…

Emily was nearly at the door when her Sponsor said, “Oh, and you know that invoicing module?  Will you make sure it does currency conversion for our international accounts?”  Emily smiled tightly.  This was the fifth change to the requirements for the invoicing module this week – and it was only Wednesday.  Last week her Sponsor had told her that the module only had to cope with national accounts.  “I’ll see what I can do,” she said.

On her way back to her desk, Samantha from Sales stopped Emily in the corridor.  “We’ve done some focus groups with customers,” she said, “and here’s what they want from the database.”  Samantha handed her a long list.  “Mostly new stuff, but these two are just rewriting some reports.  You can do it all for the launch day, can’t you?”

“I’ll see what I can do,” Emily said.  The reports had already been written.  How could she tell the development team that they would have to do it all again?  The changes didn’t even look that important.  All the requirements for this project were changing on a daily basis and at this rate they would never get everything done by the launch date.

Emily knew she couldn’t carry on like this.  She was being a doormat and just saying yes to everyone although there was no way it would all get done.  The requirements were too fluid and she needed a new approach to keep the project – and the stakeholders – on track.

Problem

At the start you thought it was great that people were so enthusiastic about making sure that the project delivered something which was fit for purpose.  If that meant a few changes here and there, so be it.  Now the changes are piling up and it looks as if you’ll never get finished if the goal posts keep moving.

Changes to requirements are common on projects.  After all, when you started out you may have had a clear vision of what needed to be done, but as the project progresses, users start to realise what is possible and ask for more features.  Or perhaps the client keeps changing her mind.  Whatever the reasons behind all the changes, you are facing a project suffering from major scope creep.

Warning Signs

  • People are changing their minds about what they want.
  • Requirements that were agreed last week are now different, or removed entirely.
  • You are spending a lot of time chasing people for agreement.
  • Your plan is out of date as soon as you have updated it.
  • The project is running late because you are having to schedule rework to cope with the changing requirements.
  • You can’t see the end of the project.

What will happen if I do nothing?

The project will drag on as constant changes to requirements mean nothing is ever completed.  Eventually, the project will be cancelled or you will be asked to step down.  The project will be taken over by someone who will be able to deliver what is needed.

Your credibility as a project manager depends on being able to complete projects and ensure they deliver business value, so there is a risk here that you’ll end up being seen in the organisation as someone who can’t control a project – which is not good for your career.

Solution

Changes aren’t necessarily bad; they just need to be handled in a controlled way. You need to stop the scope creep and make sure that everyone signs up to the current list of requirements.  And you need a way to make sure that if there are changes in the future everyone understands what the impact is of making those changes.  In summary, you need:

  1. An agreed set of current requirements.
  2. A clear understanding amongst your project team and stakeholders of the impact of making changes.
  3. A change control process.

Next Wednesday’s extract will show you how to get there.

 

Project Pain Reliever, edited by Dave Garrett, is published by J. Ross and is available on Amazon.

10 comments

Project Pain RelieverThis is an extract from Project Pain Reliever. I contributed two chapters and they are being serialised here over a month. Last week’s extract was about the issues and warning signs related to planning on your own. If you find yourself in a similar situation, here’s what you can do about it.

What should I do?

Get the key members of your team altogether to work out a new, realistic plan and schedule that they can all buy into.  Acknowledge that your current working plan is no good and that you need to set a new baseline against which to track progress.  Essentially, you are starting to plan this project from scratch, and you need their help.

Document all the tasks

As a group, review all the work breakdown structures and plans you have so far.  The person doing a job will have a better understanding of what it actually involves than you ever will.  So let them tell you what is required to get the task done.  What is missing from the original plan?  How does the task break down into sub-tasks?  If you can, delegate the creation of sub-plans to the workstream leaders.

The aim here is to get a comprehensive list of what needs to be done to achieve the project’s objectives.  Rely on your experts to help you develop this list – it will help them feel more accountable for the deliverables, and more comfortable with the overall plan.

Understand the dependencies

Once you know what needs to be done, it is time to start putting the tasks in order to create the schedule.  Dependency management is important here.  Again, rely on the experts in your team to help you build the dependencies into the schedule.  Take into account:

  • What order do the tasks need to be completed in?
  • What tasks can be run in parallel?
  • What can be started early?
  • Who needs someone else to have finished before they can start?
  • What needs to finish at the same time as something else?

Once you understand the order of tasks and their dependencies you can start putting in some dates.

Create the schedule

The team didn’t think much of the original schedule you created, so this time ask them for their input.  They have probably spent more time carrying out this type of work, and unless it is a unique project or they are very new to their job they are likely to have done it before.  Given all their experience, they should be able to come up with some realistic estimates for timeframes for all the tasks on the plan.

There is no harm in challenging some of the dates – you don’t want the team to be able to pull the wool over your eyes.  As the project manager you should find a balance between making up the milestone dates yourself and allowing the team to define their own dates so far in the future that they all get to work half days and the project takes ages to complete.  Work together to create stretching but achievable target delivery dates.  And put some contingency time explicitly in the schedule if you are worried that there is a degree of uncertainty in the estimates.

Finally, it’s time to present your new schedule to your Sponsor.  It is highly likely that the result of doing this exercise is a project that will finish later than you originally had in mind.  It’s difficult to tell a Sponsor that your initial estimates were wrong.  However, what you now have is a project plan that you can believe in, deliver to and that is backed by all the members of your team.  That’s the message to give your Sponsor.

You know you are in a good place when…

You know you’re in a good place when:

  • You have a comprehensive list of tasks for the project.
  • You understand the dependencies between tasks.
  • You have worked with your team to set realistic estimates for the duration of these tasks.
  • You have built a credible schedule with input from your team.

You are not the expert when it comes to carrying out the work for each of these tasks – so draw on the expertise in the team and involve team members when producing a plan and schedule.  You will get better buy in from the team as a result, and everyone will have more confidence that the project will deliver on time.

 

Project Pain Reliever, edited by Dave Garrett, is published by J. Ross and is available on Amazon.

2 comments
Qualifications

What credentials should individuals or employers choose?

Project-related work and the number of project-related jobs are growing too quickly for our approaches to professionalism to keep up.

You don’t have to look to hard to see that the world of work is becoming more focused on projects. I don’t think it’s just project professionals who would say that – business leaders are also aware of the fact that projects are a core part of any company, and project management standards and approaches are being applied to more things. Ben Snyder even called his book Everything’s a Project.

In parallel to that, the role of the Project, Programme and Portfolio Office is growing. There are different types of roles available now to people who want to work in projects. You could be a PMO specialist, a risk professional or a project support officer. The management frameworks and organisation structures that support project-based work are in use in many companies.

But what does ‘project management’ mean?

While the growth is good, what I am also seeing is that project management has different interpretations for different people. Project management jobs are offered with salaries of £20k to upwards of £80k. That can’t possibly be the same job with the same responsibilities.

Project management ‘professionals’ (i.e. you and me) have taken the approach that industry bodies are the right groups to explain what project management is. In the US, this is relatively clear, as PMI sets the standards for what project management means. I don’t say this because I’m a particular fan of the Project Management Body of Knowledge or the PMP credential, but because in the US there isn’t as much competition between industry bodies.

In the UK it is a different story. We have the Office of Government Commerce, which produces the PRINCE2 and MSP frameworks. These are the de facto requirements for project and programme managers over here.  We also have the Association for Project Management which is affiliated to the IPMA. They have their own body of knowledge and credential scheme. Then we have a small but relatively active PMI Chapter, so there are people with PMP and other PMI credentials.

For employers, it’s a mess. Do you want a PRINCE2 Practitioner or a PMP, or someone who has both? What does APMP mean and it is better or equivalent to a Master’s degree in Project Management? If I want to recruit a PMO Manager, what should I be looking for? There is no national standard to help employers make the right decisions for their companies.

For individuals, it’s worse. Most employers advertise for people who are PRINCE2 certified, but that course won’t teach you to do proper scheduling and it certainly doesn’t reflect your experience in the field. So should you get PMP as well? What about the new Registered Project Professional designation from APM? This is in its infancy but the idea is that people who have RPP then adopt Chartered status and become Chartered Project Professionals when the APM is awarded its Royal Charter. That will apparently move those people into the same stratosphere as Chartered Accountants or Chartered Surveyors. So let’s say you want to go for that. Who will pay for it? Many employers will only pay membership fees to one professional body for you (or none at all). Do individuals have to pay for PMI membership and APM membership and ask their employers to send them on PRINCE2 courses every 5 years for recertification?

There’s no clear path to solving these problems

I don’t have the answers. This is a challenge for industry bodies, employers and individuals. Professional bodies won’t suddenly stop producing certificate-based courses. It is how they make money and how they convince employers that they are relevant to today’s working environment, and for the most part the courses and credentials are very good.

I don’t have an issue with the standard of project management education – I just worry that there is too much off it, which makes it hard for employers and individuals to know what is the best option for them.

I can’t see that any of the professional bodies in the UK would give up marketing their services because someone else is doing a similar thing. What I would like to see is more alignment and collaboration between them, so that it is easier to compare bodies of knowledge, standards, frameworks, certificates and credentials and whatever else is out there. This has started – there is movement towards bridge courses between credentials, and training courses are being marketed specifically at people who have a different qualification.

We need project management as a profession to hang together, not become more fragmented. The project-based workplace is here to stay, and the discipline of project management needs to catch up pretty fast so that companies see the value and know where to turn for professional advice. What should we be doing to help that happen?

This article is based on an interview I gave for The Project Management Podcast last year.

9 comments