The Money Files

In this instalment of my irregular column chatting to expert project managers, I caught up with Chris Cook. Chris is the author of a new book, The Entrepreneurial Project Manager. It talks about how you can improve your skills to take a cutting-edge approach to project management, as an entrepreneur does in their own business.

How does that work? We’ll get on to that. First, I asked Chris to share his background and how he got into project management.

Chris, tell me about your career path.

Out of high school, I started working for my stepfather’s road construction company. I started as a general labourer eventually becoming a surveyor (of sorts).

I was attending college studying building construction management. After graduation, I enrolled in the graduate project management program at the same university. I was working and going to school. The field and classroom knowledge blended well.

Did you always know you’d write a book?

Five years ago, I was laboring for my stepfather’s company while studying project management in graduate school. I was coming home with dirt head to toe, tired like a dog from the weather and long hours, and I had no idea what the next move was going to be.

Would I stay working for him and maybe take over one day? Would I leave and spread my wings with a larger company to put my studies to use?

While working as an assistant project manager for a different company, a professor from graduate school offered me the opportunity to write a book for a publisher she has worked for. I jumped at the opportunity. Over the past year, I have been focusing on writing the best book possible, learning about the book writing process, and pursuing more knowledge of the project management profession.

Now, I am 1500 miles from home in Colorado having written a book, completed graduate school, and became a PMP®. Only one of those goals was on my mind at the time.

I’m guessing it wasn’t the book! What was the writing process like for you?

I segmented the process into three parts: research, writing, and editing.

The research phase took the longest. Writing notes, picking materials to use, watching hours of webinars and videos, and then placing those notes into designated chapters. I wanted to use materials not only within project management but also outside the project management world.

I tend to look at project managers as leaders and coaches, so I reference sports quite a bit throughout to make the comparison more concrete.

The writing phase was transcribing those notes through a project management filter (in my head) relating coaching and leadership to a project manager.

My goal was to write on a subject then set the computer down. A piece of advice I took to heart was if you still have something to write about, stop writing. Pick that thought up the next day to keep the momentum going.

Editing was the last phase and most excruciating for me because I had to then read what I wrote and become critical. I had amazing people who read my work and gave excellent feedback along the way which drastically improves my writing.

You did a lot of research for the book. What in particular did you do on the subject of entrepreneurship?

Entrepreneurship and outside-of-the-box thinking are often linked. I tried this same approach in my research. Instead of going to best-selling entrepreneurship books that most people read, I attempted to look for outside sources that can be linked similarly.

For instance, I read many coaching and leadership books because a project manager holds a similar position on his or her team. Hall of Fame coaches Bill Walsh and Bob Knight are two of the sources I went to for more information on taking teams to a championship level.

I also applied Stoic and Taoist philosophies because it is important for people who are leaders to understand their personal stances and why they do what they do, or believe what they believe. Making individuals perform for the sake of performance does not inspire or lead to betterment.

However, if you give reasons and data as to why these tasks are essential, the group is more likely to respond positively. “Because that is how it is done” or “this is how we do things” is not a substantial enough answer.

People might think that intrapreneurship is more relevant to project managers working in a big organization. What are your thoughts on that?

Intrapreneurship is a great concept that gives employees the opportunities to use company resources with expansive thinking and testing to innovate.

The first time I came across intrapreneurship was the PMXPO 2016 when Robbie Bach gave a presentation regarding his time with Microsoft and developing the Xbox gaming system. The only knowns Bach had were competing with Sony for the living rooms of consumers and a deadline. Other than that, the project was open ended. Each person became a firefighter coming into work not knowing what fire they would have to put out that day. Even with a $4-6 billion overrun, Bill Gates and Steve Ballmer still considered the lessons learned worth it. Bach implemented his 3P framework: Purpose (Pursue the Northstar), Principles (Ground Rules), and Priorities (The Art of Leaving Things Undone).

Watch the video of Robbie Bach’s presentation here: PMXPO 2016: The Xbox Story: Lessons in Leadership, Strategy, and Team Management

Most of the time, people get caught up in the bureaucracy, hierarchy, and rules of an organization that creativity and innovation get lost. A lot of time is spent performing defined tasks and schedules, and before you know it, the day is done, and the train keeps on moving.

I like the idea of finding time to brainstorm, revert to a child’s mind, and be playful with idea creation. Not all ideas are good, but that should not deter someone from shouting them out just in case.

Thanks, Chris!

The Entrepreneurial Project Manager by Chris Cook is published by CRC Press

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!