The Money Files

I’ve been catching up on some reading over the summer, and Edoardo Binda Zane’s book, Writing Proposals: A Handbook of What Makes Your Project Right for Funding, has come to the top of the pile.

It’s a book about how to write a compelling argument for getting cash to do your project. Aimed predominantly at people trying to secure public funds for their initiatives, I think there’s plenty in here that would be helpful for project managers writing business cases or proposals outside of the public sector too.

The book is split into 3 sections:

• Workflow: this talks about how you gather the information for your proposal and put it together in a way that is the least amount of work and doesn’t require you to keep editing and aligning the main document.
• Writing techniques: Tips for making your writing stand out to the person who is reading a dozen of these proposals.
• Proposal-specific writing tips: Further advice on making sure your proposal is a polished as it can be and that you are totally clear on what you are asking for.

A Practical Step-Through Guide

What surprised me about this book – and I don’t know why, because it’s clearly marketed as a book to make proposal writing easy – is that it’s literally a guide to what to put in what section. It’s almost like cheating.

Binda Zane tells you how to write it and what to say. There’s even a downloadable proposal template and budget sheet in case you need them. It’s a step-by-step guide to getting your proposal accepted. Just do what he says in the order he says and – while it won’t guarantee you funding for your project – you’ll certainly have a far better chance of hearing ‘yes’.

Technical Proposal

The largest part of the book focuses on how to write the technical proposal. It’s about putting together a work breakdown structure, describing what you are planning on doing and creating a realistic budget.

There are lots of tips in here, and while the author only hints at his past experiences early on in the book, it’s clear this is hard-won advice. You can tell he’s earned his stripes!

Tips for Clear Communication

My favourite tips were around using visual planning to get the message across, and thinking about how your proposal actually looks.

For example, he suggests taking out some of the extra stuff like staff profiles and putting them in an appendix. It saves the document from looking too bulky (and your word count, if you’re limited) while still providing the information required.

Binda Zane also encourages you to use Gantt charts and diagrams to explain the project and your methodology. Don’t worry if you are an Agile team. If Scrum is more your thing, there’s a section on how to create a timeline for your proposal without having to use a waterfall-style Gantt chart.

Worked Examples

Sometimes it’s hard to visualise what your finished proposal should look like, so the author has included worked examples, especially around calculating hourly rates and working out your budget. There are also examples of clear writing: it’s a lot easier to tell the difference between poor sentence construction and good sentence construction when it’s right there on the page in front of you.

It’s a short book. I read it at the soft play while my children romped on the giant slide and sat inside a submarine. That points to how easy it is to get through: if I could concentrate on the book, a latte and the kids then it’s definitely an accessible read. I can think of three or four project management books where I wouldn’t have been able to get past the first page due to the density of the writing.

Writing Proposals: A Handbook of What Makes Your Project Right for Funding by Edoardo Binda Zane is available here.

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.