The Money Files

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!

So you want to go with Earned Value as a way of tracking time and cost performance? Good for you. Here are 5 pre-requisites that you’ll need to consider before you really get into the detail of doing the work.

Oh, and this assumes that you’ve already ticked the pre-requisite that is ‘team and manager on board for a major change in how we track project performance’ because EV is quite a culture shock to the uninitiated.

With that out the way, let’s dive in!

Pre-req #1. Detailed Scope

You’ll need to have a work breakdown structure in place, with a degree of detail you perhaps haven’t had to focus on before.

In order to track your progress against your scope you have to know what the scope is. Without that, you’re going to struggle to get any degree of accuracy in your reporting. Break down your tasks to a decent level as well, so that you aren’t struggling to report progress on a task that’s gigantic.

Pre-req #2. A Timetable

Armed with your breakdown of tasks you can then start adding dates to them. Again, if you want to track whether you are hitting your milestones and working ahead or behind schedule, you need to start from somewhere. This is your baseline schedule.

Build out your dates for each element on the work breakdown structure. Make sure they take into account the fact that your estimates are realistic and that you’ve got the agreement of the team member involved before committing them to anything.

This is the point to layer over your resourcing and capacity planning, so that you aren’t scheduling work in a vacuum. Take into account holidays and other absences so your schedule is as accurate as it can be.

Pre-req #3. A Breakdown of Costs

Earned Value is only good for tracking time and cost performance. It’s very good at that, but it’s not going to give you the context for changes or a feeling for how quality is being achieved (or not). The timetable gives you the info you need to start thinking about tracking time; a cost breakdown structure gives you the info for tracking cost.

Take your work breakdown structure and cost it out. Whether you do this top down, bottom  up or some other method of applying costs to work packages – it doesn’t really matter. However you get there, the end result is the same. You should be able to apply a fixed cost to a piece of work that has a scheduled completion date.

Pre-req #4. A Plan for Reporting Progress

Next, you need to establish an approach for reporting progress with the team. This sounds more straightforward than it is because you’ll need to be able to say what % complete through a task is, and some tasks don’t breakdown nicely.

For example, if part of your task involves ordering kit and then you have to wait until it’s delivered and then you do something with it to set it up, your work and expenses aren’t going to be evenly spread across all the days allocated to that task. It would be better to split the work into two tasks: Order Kit (which finishes at the time that the kit is delivered and costs as much as the kit costs) and then Do Something With Kit (which takes as long as it takes and costs the amount you bill for resources).

Generally you’ll report whether a task is not yet started, in flight or complete, so you should to agree whether the % complete targets of 0%, 50% and 100% are adequate for your needs. And, for each task, what 50% looks like. That could be quite easy with some tasks, especially where the work is spread evenly over the time – it’s where work isn’t spread evenly that makes it a bit harder to predict.

You can go as granular as you like but don’t get so hung up on working this out that you never get started tracking EV in earnest.

Pre-req #5. A Plan for Collecting The Data

When you’ve got agreement on how progress is going to be measured, you should agree with your team how they are going to get that progress to you. This is likely to be in the same way that they do now, in your non-EV world, either through checking in with you during the task formally or informally, completing a status report or giving an update at your regular team progress meeting.

It simply sets expectations so that everyone knows what they should be doing and when.

With those 5 pre-requisites in place you should be good to start monitoring time and cost performance with your EV spreadsheets and tools.

I found a good (short) video from Simon Harris introducing EV so if this article has given you the appetite to take it further, watch this.