The Money Files

So you want to move to using earned value. As a way of communicating project status, the charts are visual, the picture becomes clear and it’s a great way of explaining progress. Once you understand what you are looking at then you can get a great deal of information from a single report.

However, you’re probably a bit daunted by the move because EVM has a reputation as being difficult to understand. You might have learned the theory as part of your PMP® exam preparation but you might not have looked at those formulae since.

If you’re convinced that EVM is the right move for you and your team, it’s the same as implementing any new way of working: get the buy in, define what you want to do, plan it, implement it, review.

Let’s focus on that first point, getting buy in, for a moment.

If your team aren’t behind you, actively supporting you, not just passively nodding in a meeting while at the same time dreading having to do it in real life, then you’re going to find it a lot harder to switch to a culture of using earned value.

This isn’t news: it’s simply change management. One of the biggest issues I think we as project managers have is doing change to ourselves. If we think of these initiatives as a project, with all the associated project management disciplines including change management, then we’re going to have much better success rates.

Getting buy in from the team

So how do you get buy in from the people doing the job?

First, identify who is going to be involved in using EVM or interpreting the results. These are your stakeholders.

Then start your programme of communication and change management. For example, identify their concerns. If it was me, I’d be worried about the maths and what I’d actually have to be doing each time I put together a report. I’d want clear guidance on what was required.

I’d also be worried about the accuracy of the reports, knowing that my current project’s scope and schedule aren’t yet solid enough to do any meaningful reporting from. How is that going to work? At what point in a project is EV going to kick in? And what if I never get my schedule baselined? (Because, you know, it’s one of those projects. Don’t judge, OK?)

Identifying and addressing concerns goes a huge way towards gaining the support of the team. If they feel like they can manage the change (whatever it is) and have confidence that it won’t be as awful as they are possibly expecting, then they’re going to feel better about the process of getting there.

A big chunk of change management is communication, and you can keep the team on side far more solidly if you keep them abreast of what’s happening. It’s not good to dangle the carrot of EVM and then provide no updates for three months. That just breeds uncertainly because when people don’t know the truth they have a habit of making stuff up to fill the gap. Not maliciously, but something heard on the grapevine becomes a “fact” once it’s been through half a dozen people at the water cooler. So keep the communication channels open. My book, Communicating Change, has a number of ways to do that if you need some suggestions.

Getting buy in from above

Everyone has different preferences when it comes to taking in information. In our office, a couple of teams have their personal preferences displayed on their desks following a team building event, so you know when approaching them to lead with facts, emotion, detail or something else.

As a result of personal preferences, the way you gain buy in from senior managers is going to be different depending on the person. The exec who likes facts is going to want to know that it’s going to deliver standardised project reporting, improve forecasting by X% and give us the data to better control project performance. (Or whatever, you get my drift.)

The exec who prefers to understand the human impact might be influenced by the story of a single project which, using EV, turned in better results because the project manager could more easily control the work and people on the team had better visibility of progress against cost.

Unfortunately that means that there isn’t a magic formula that I can give you for gaining buy in at senior levels, but in my experience all execs do have one thing in common: they like solutions that save time, save money and increase profitability. Standardisation and repeatability are also good selling points. In other words, initiatives that improve project management maturity aren’t particularly important, unless you dress them in the language that business leaders want to hear.

Then you have a powerful story.

What has been your experience of implementing EVM? Did you struggle to get buy in from people? I’d love to hear how it worked out for you.

When you’re putting together a new project proposal, there are a number of things to consider. Edoardo Binda Zane has a whole book about proposal writing: Writing Proposals: A Handbook of What Makes Your Project Right for Funding. He says that there are three main elements:

• The technical proposal, where you set out your solution or project objective
• The administrative proposal, where you prove you are eligible for any funding
• The budget.

Project proposals of this kind are quite different from in-company project business cases. These relate to projects where you are basically pitching another organisation to give you funding for your project. This happens in research, academia and sometimes other areas like business incubators for start ups.

Let’s say you want to put a funding proposal together for a business incubator. You know you are eligible and you’re gathering the paperwork to prove it. You can put your budget together in the format they want. But the technical proposal…. It’s hard to know exactly what goes in that, even if you know your own solution perfectly and have already costed it. This is about communicating the value and approach of your project so it gets chosen over someone else’s.

It helps if the funding-granting body has given you a template to complete. That certainly takes the guesswork out of it. If that doesn’t happen, you’ll be reliant on your own internal templates and they might not be geared up for this kind of application.

Binda Zane has some pointers for what to include. The headings below are what he suggests goes into your technical proposal along with an explanation of how I would interpret those if it was my project.

Introduction

Pop something in here to set the scene. Personally I would write the introduction last so I could make it contextually relevant to the rest of the document. If you don’t normally leave it to the end to write the intro, try it next time – it’s so much easier!

Current context and proposal structure

This should cover the context of the project and any background information that’s useful for the decision makers to have. It could also describe the research you’ve done (not in detail) or other sources from which you’ve drawn information to prepare this proposal.

It’s also a kind of executive summary that outlines what they can expect to read in the proposal and gives them the headlines in an easy to digest format.

Methodology

You’d cover off the project goals and objectives. This would be just like a standard business case.

Binda Zane suggests that you talk about the tools and techniques to be used. This can give the decision makers confidence that you do have some clue about how to manage a project. If you can say that you’re using industry standard best practices and following guidance from PMI (or whatever methodology/standard/processes are applicable to your business) then do.

I’d make sure that governance gets a significant mention here. If you were asking for my money I’d want to know that you had controls in place to spend it sensibly.

Of course, you shouldn’t say that you can follow standards if you actually can’t. That would be a breach of the PMI Code of Ethics and Professional Conduct. Other professional bodies have similar ethics standards.

You’d also want to include a section that outlines your detailed approach, the work packages and the descriptions of each task, at least to a sensible level that tells them what you are all about. If you think this section might go on a bit, move some of the task descriptions or detail to the end and put it in an appendix.

Organisation and Staffing

This section covers what they need to know about the people who will be involved with the project and how the work would be organised.

Binda Zane suggests management of quality control is covered in this section but I think there’s some flexibility to move it elsewhere if that makes better sense to you. I think I’d include this in my methodology section but there could be good reason for keeping it here.

Up until now you’ve only talked about what you will do, and how you will do it, but there hasn’t been any talk of how long that will take. Mention the timescales, major phasing and anything else relevant: key milestones, reporting dates and so on.

You also want to talk about the project team in this section. Describe the make up of the team, the organisation structure for the project and the roles and responsibilities of the key players.

Appendices

Binda Zane recommends two appendices. You can dump information in here that would take up too much space in the main proposal but is still useful for the audience to have. His suggestion is that you include the CVs/resumés of the project team and also a selection of project references. By that I would surmise that you could include references from past clients about similar projects, awards your team has won for their project work and anything else that makes you look like a solid and stable organisation.

That should give you a solid project proposal – for the technical element, at least. What else would you include in a technical proposal? I’m interested to hear your thoughts about what might be missed out of the list here!

Wyzant (say: Wise Ant, I think), a marketplace that matches up tutors and students for in-person and online study sessions, has done some research into how people feel about working with numbers.

They surveyed 235 students who recently struggled with statistics. Only 5.5% of these students were pursuing a career in a maths-related field, and many called out business or project management as a potential career path.

That’s a lot of people who don’t intend to use maths as their ‘full time’ day job who are using statistics as part of their course and possibly their future job. Nearly 45% of the students said, “I’m not a maths person,” which is the answer I would have given too. If you hold that view about yourself, you’re creating more stress, anxiety and mystery around the basics of statistics.

What People Struggle With

70% of all the students struggled with the same two statistics concepts, hypothesis testing and probability. 

Personally I don’t use hypothesis testing in my project management work, but I’m sure understanding it is essential in some industries. It hasn’t been since university that I’ve had to think about hypotheses, thankfully. My days of having to understand T-tests and ANOVA are hopefully long gone… if I ever truly understood them at all.

Probability, though – we’re all exposed to that as a function of risk management. It’s often so simplified though that risk assessments are subjective: “I think that my risk is not likely, likely, quite likely, almost definitely going to happen.”

Understanding Probability

Wyzant worked with expert tutors in the field of statistics to identify the concepts and break them down in ways we can all understand. The article quotes PhD candidate, Brian, who tutors university students in stats:

“Typically, when students are introduced to the normal distribution, they’re given a curve and told probability is the area under the curve. But this is still confusing.”

He says it’s easier to think of probability if you break up the area under the curve into 100 squares, each equal in size.

“If you can look at the distribution and say each of these squares is equal to 1% probability, you can just count the squares to develop good intuition about what the normal distribution is and what it means.”

Image credit: Wyzant

I can see how thinking about probability in this way would make it clearer. The bell curve of a normal distribution is all well and good but blocks really call out the way that the 100% is made up and how it spreads out across the distribution.

What do you think?

The website has some helpful guides for common statistics and probability concepts as well.

You might also find this book interesting: Math for Grownups. I certainly found it helpful!

What should you take into account before you make the investment in project management training? Here's a quick video on the 5 things you consider.

You can get more detail on the points raised in this video in this article.

One of the things I get asked the most is, “Can you help me with my business case?” It wasn’t always like that, but I think these days project managers are getting more and more involved with writing business cases. We’re taking in part in the project from an earlier point, which often means before the project is even really a project.

I’ve written quite a lot about business cases over the years so here’s a round up of resources that can help you put together a fantastic business case.

Business Case Basics

To get started on a business case you need to know the purpose of a business case, who is going to read it and the 7 essential elements that go into a standard business case. If you’re starting from scratch, these two articles have got you covered:

• Business Case Basics Part 1
• Business Case Basics Part 2

As with all things in project management, understanding the ‘why’ is a huge benefit for understanding the ‘how’. The 3 reasons why business cases are essential are:

1. They specify the problem that has to be solved
2. They justify why it’s worth spending time fixing the problem
3. They provide information on the solution that helps decision makers prioritise the work and the investment required.

These reasons apply whether or not your company cares much about paperwork and bureaucracy. As a project manager it’s still important to understand why your project has value to the business. If you’re struggling to get your management team to even the shortest business case, keep pushing! It will massively help your project management maturity levels.

And you can watch a short video all about those in more detail below.

Business Cases for Program Management

Programs need a slightly different approach to justifying a project through a business case, although there are many common elements, and the reasons why you would do a business case (to specify the problem, justify the work and explain the solution) are still relevant.

There’s a whole stack of information on preparing a program-level business case in this summary I put together from Program Management (Gower, 2010), by Michel Thiry: What goes into a preliminary program business case?

You’ll see that there is still a great deal of detail required from a benefits realisation plan to resource requirements, and a statement of achievability. It’s a significant amount of work even to get to this  position of having a preliminary business case.

Once you’ve got approval in principle to continue with your program, you’ll be able to put together a more detailed program business case. You could argue that this document (again, I’ve pulled together a high level view of some of the ideas outlined in the Program Management book) borders on being a Project Charter, because by this point you’ve had approval for the concepts and solution so you aren’t spending too much effort thinking about options appraisal any longer.

However, there’s also an argument for saying that options appraisals are more suited for solutioning at project level, and at program level you’re really approving the transformative change.

I wrote a recipe for a program business case as well.

 More Resources for Business Case Preparation

If you are writing a business case you’ll find this book interesting: Business Case Essentials.

Finally, here are some tips for preparing a business case when your project is all about implementing online collaboration tools. There are some specific things to consider that will help make your proposal more appealing, and it’s especially worth thinking about non-financial elements and how to justify those.

I hope these resources are helpful for you!