Guide to project planning
The overall goal of project planning
Understand the client’s high level objectives
“Love the problem, not the solution”
Where does value come from, and how do you unlock value as quickly as possible?
What are the risks, and how do you prioritize to address them?
Start with a narrow focus and expand if successful
Define success, be specific, start with the end in mind
Conclusions and recommendations
Projects are abstractions and communicating about them effectively is a skill
Skill - identifying structure and communicating in a structured way
Skill - communicating visually
Skill - communicating data optimally
Tool - project workflow diagram
In mature industries (constructing a highway overpass), the primary goal of project planning is to manage the schedule and budget. But many of you will be working in new industries or research. You will not have established templates to follow, and you will be expected to manage significant uncertainties. It is therefore critical that you understand planning in a fundamental way, and that you are able to adapt your planning skills to any project or problem.
Some objectives of planning include:
The importance of performing background research is almost too obvious to state, but every year we see teams that don’t seem to have done even five minutes of Googling. Background research is necessary to:
A bit of coordination and strategizing with your team can deliver results quickly. For example, each member can do a bit of individual research first, and then you can come together as a group to talk about “themes”, “structure”, “open challenges”, “clarifications needed”, etc.. You could then agree to each research one or a few topics, breaking up the work to dive deeper, and all start contributing to a common Google Doc.
In probably every project you will ever undertake, your immediate requirements will be only a part of some larger project. Instead of simply accepting and acting on your requirements as written, it is important to understand the sponsor’s overall project objectives and how your requirements derive from these. Why is this important? If you have an understanding of your sponsor’s broad objectives, you will be able to manage and optimize your own sub-project more effectively and more independently. For example, if you were leading the aerodynamics sub team for BMW’s new super-efficient prototype car, and you weren’t aware of the highest level objective (efficiency), you would probably need to check in with management and every other sub team for every little decision. But if you knew that efficiency was a higher priority than, say, sticking with historical BMW styling cues, you could make better optimizations.
Elon Musk, in his excellent July 2021 tour of Starbase with Everyday Astronaut’s Tim Dodd, talks about how everyone should, to some extent, be the chief engineer, so they can understand the system at a high level and avoid making bad optimizations. This is an addendum to his very useful five step process. Not all of these apply to capstone, but they are certainly worth knowing.
Similar to understanding the high level objectives, it is critical that you understand the problem that you are being engaged to solve, not simply the solution that you have been asked to develop.
Sponsors will often already have in mind what they think is the best way of solving a problem and they will want to get straight to work. Sometimes this is good, sometimes it isn’t. For example, if you are working with a physicist at TRIUMF, they’ve likely spent years on the problem and there are probably many constraints that point to a fairly narrow range of solutions. Great. But often sponsors have a vaguely defined problem and they’ve latched onto one solution and then spent days, weeks, or months ruminating on this single solution, imagining all the details. This is “loving the solution”.
Your job is to first understand the problem. Ask lots of questions, and be open that your intention is to understand the problem as fully as possible. Problems are multifaceted and multidimensional, so you can try to understand relative priorities and relationships. Work with the sponsor to identify, hopefully, narrow and precise statements about the problem. This is “loving the problem”.
By doing this, you’ll often be able to reformulate the problem in an entirely different way, where the path to investigating the critical questions that will unlock value for the sponsor is much shorter, clearer, and lower risk.
In our first meetings with you, we will brainstorm about how your problem could possibly be reformulated to accelerate the project.
All of the above said, your job is not to disagree with the sponsor and to push them in a new direction. If you can help them find a more efficient and focused application of the limited project resources, and they agree with you, great. But if they are set on a particular direction, you should do your best to understand why they are set on that direction, appreciate their perspective, and then try to move forward as quickly as possible.
Often sponsors will talk about their objectives in fairly high-level terms. They will want something to be “better”, “faster”, “more sensitive”, “more accurate”, etc. Some projects have non-technical sponsors, or the problem hasn’t been closely technically defined, and it will be up to you to really boil down these broad objectives into more precise statements. Or, the sponsor might be very technical, but they just haven’t yet thought deeply about precisely what they are after.
Use your curiosity, a healthy dose of Wikipedia, and annoying persistence to dig in and distill the problem down to the fundamentals. Don’t be shy about asking what might seem like dumb or naive questions:
Often asking these very basic questions will lead to all kinds of realizations that have a huge impact on the project scope. For example, perhaps everyone has just assumed that it’s a simple matter to get a precise and uniform temperature across a device and by asking a simple question you force the realization that heat flow will lead to temperature gradients and the type, location, and mounting of the temperature sensor will have a huge impact on the device performance. If you don’t do a deep dive, and instead just say, “Mmmm, precise temperature control, got it,” and then go on to wireless connectivity, smartphone app, etc. etc. you will be caught off-guard when your device does not behave as expected and you’ll wish you’d invested all of the time spent working on the (now useless) smartphone app on the temperature control problem instead.
Also, really try to identify the core physical, mathematical, computer science, information theory, etc. concepts that govern your project. Do you need to understand:
If you really dig deep enough you should be able to identify a small number of very clear problems or tradeoffs that underlie vague objectives like “better” and “faster”. In your proposals, presentations, and reports, we will be looking for an awareness of these fundamentals and how you have crafted your plan to address these in a targeted fashion.
In many projects, you won’t be able to identify clear parameters right at the start. That’s okay. Often things become more concrete as the project progresses, but it’s important as a project manager that you keep track of this, and keep driving the team/project towards more specificity and clarity: “Hey everyone, we still don’t have a clear idea of what we’re shooting for and how we define success… But we’ve learned a bunch in the past month, maybe it’s time to revisit our objectives?”
Please keep in mind: it is okay for you to say, for example, “I don’t know how deGaussing works, but it is critical to this project, so we’re going to learn about it.” Identifying knowledge deficits is a critical activity and we can reach out to experts for help, if needed.
To “get the best bang for the buck”, you will need to be strategic in how you define your objectives and prioritize your project plan. You could sketch out a diagram of the entire system and then assign team members to just start working on everything. This might be okay if your project is low risk (The new Kitchenaid blender, now available in red!), but in risky and novel projects, this is likely to be extremely wasteful. Every project is different, and you’ll likely want to use a combination of prioritization strategies. Overall, as a project manager you must always be able to justify why your current plan and priorities are optimal. Here are a few strategies to consider.
If you were contracted to develop a mobile banking app, for example, it might have many different interconnected subsystems that will all need to be implemented eventually. But if your client is a small startup and they are trying to differentiate themselves by having the first banking app that can interpret spoken natural language (you can talk to it), you might heavily prioritize getting the natural language processing (NLP) functionality up and running and not even worry about database integration, security, etc. If they are the first company that can use NLP to effectively interact with bank customers, that’s a big deal, and it should be easy for them to raise additional money to build the app, implement industry-standard security, etc. But if they have an app that looks and functions like everyone else’s and their supposedly differentiating NLP technology isn’t working, no one will care.
So, always have a clear eye on what is new, different, important, valuable, enabling, differentiating, etc., and prioritize/focus your plan with this in mind. Discuss this with your client/sponsor - they may have several other constraints and objectives beyond technical development (like needing a “real looking” demo for a trade show).
While all projects contain risk, there is a huge difference between established industries with known risks and new industries or R&D, with unknown risks. If you are building an overpass you’ll need to manage schedules and budgets, secure materials at reasonable prices, and keep track of contractors. But the fundamental concept of building one road over another should be risk-free. This is not the case if you are designing a fusion reactor. You’ll need to continually assess and reassess what you do and do not know about your project, what could go wrong, and the order of your priorities in order to manage these risks.
As a project manager, you should regularly be asking yourself if you have the right set of priorities, given your current understanding of the risks. For example, if you are developing a new process for plastics recycling, does it make sense to be working on a truck-mounted mobile processing plant for remote communities if you haven’t convincingly demonstrated that the underlying process works at a small scale? Wouldn’t it be better to assign those engineers to solving the core problem first? If the underlying method doesn’t work, there will be no point in mounting it on the back of a truck, and this work will be wasted.
There are many ways of identifying and characterizing risks. In capstone, we may ask you to develop and track a “risk analysis”, which can take the form of a simple table. See the description near the end of this document for information on constructing a risk table.
Tracking and reporting on risks is a good way to keep everyone focused on what is important, what is driving the priorities, and how close you are to success.
With an understanding of value and risk, you can focus and prioritize your project plan. You will never have enough time and resources in capstone (or in any project), so you’ll want to be ruthless in focusing on delivering value and de-risking right from the start. A great way to do this is to eliminate or push back entire “dimensions” from your project. By “dimension”, we mean entire categories of functionality, like wireless connectivity, or user interface, or off-grid power. If you refer to the description of “scope table” later in this document, eliminating a dimension would be like getting rid of an entire row. The reason eliminating dimensions is so effective is that dimensions often start to talk to each other - the wireless connectivity and solar power system will need to be configurable in the user interface, for example - causing the project scope to grow exponentially.
So, ruthlessly constrain and focus your project plan at the start. If this is causing conflict with your sponsor, explain that you aren’t trying to eliminate work, you are just prioritizing its order to deliver value and reduce risk most rapidly. That way, if (when) you run out of time or resources, you’ll have delivered the best bang for the buck.
A project plan can take many forms, but in capstone we usually ask that you develop a project flow chart that demonstrates how you have structured and sequenced your activities according to your understanding of priorities, whether this is driven by value generation, risk reduction, or some combination of these and other strategies.
In any case, we want to see that you have really thought through your plan and tried to squeeze out as much efficiency as possible. We will help you iterate your plan, but some things to think about are:
Overall, we’ll be taking a close look at how you’ve structured and sequenced your plans and hopefully there aren’t obvious efficiencies that have been overlooked. As a project manager, your plan should always be optimized so that the only way to speed it up is to have more people and/or money allocated to it, or to have the scope reduced.
In any project, it is critically important to define what success means with the client before you start. Even though you might have a well thought out plan and a tight project scope, if there is no discussion of what success means, you are setting yourself up for conflict at the end of a project. This is true whether you are undertaking a multi-year, multi-million dollar consulting R&D project, or you are simply demonstrating your prototype to a potential customer. In either case, if you don’t first come to some agreement on “This project will be successful if we…” you will find that over time the definition of success and the client’s expectations will creep, and the project will never end.
The definition of success is usually captured by the objectives and the deliverables, both of which will be described in your proposal. In an ideal world, you could identify specific and quantitative descriptions of the objectives and deliverables, so that you and the client can agree on exactly whether objectives have been met. Often, however, you’ll have to deal with hazier definitions of success, especially at the start of a project. Over time, though, and especially toward the end of the project, it is important to try to firm things up.
When you are planning and negotiating your project with your sponsor, it can be very helpful to think about the end stages, or to “start with the end in mind”. Discussing the deliverables can help both parties realize that the project scope is actually quite large, and that it needs to be focused more tightly. Anticipating conclusions and recommendations can help to identify project tasks that might otherwise be missed in the planning stage.
What exactly do you hope to provide at the end of the project? In many cases it won’t be possible to state this explicitly, or in a ton of detail, but it is very informative to take a rough shot at this while you are in the planning stage. If you expect to generate important data, what form will this take? What are the axes on the plots? How many samples do you need to test? How will you measure uncertainty? If you are developing a prototype, close your eyes for several minutes and imagine using it. You’ll likely have several realizations along the lines of, “Oh, it will need to interface with…” or “We will need a button that...” or “It will need to sense when…” When you are imagining your final deliverable, it will of course seem grainy and blurry. We’re not expecting that you can magically fill in all the details at the start. We’re simply suggesting that this is a good way to realize just how many details will need to be filled in, just how big your project is, and just how important it is to have a narrow and deep focus on a few dimensions.
What kind of conclusions and recommendations do you want to draw at the end of your project? If you don’t think ahead, you’ll likely end your project when you run out of time or resources and you’ll struggle to define conclusions based on the limited test data you’ve cobbled together throughout the project. Your recommendations will likely just be generic statements on how the work should continue. This is not very valuable.
Instead, if, as part of your planning project, you push yourselves (and the sponsor) to think about what powerful and valuable conclusions would be, and what actionable recommendations would look like, you’ll have a much better chance of delivering significant value. Doing this at the start of the project will really help you focus your plans to ensure you investigate and answer the specific questions that will lead to valuable conclusions. You’ll identify specific tests that will need to be conducted to support conclusions and you will have the necessary data on hand when you go to write your report. Doing this early will also help you realize the true scope of your undertaking, and will encourage you and the sponsor to focus even more narrowly on the critical, high value items first.
How do you actually talk about a project in a coherent way? You’ve probably all participated in at least one meeting where you felt like the conversation was going around in circles, or where it was clear (to you at least) that different participants had completely different ideas about something, even though there was a lot of head-nodding.
If you can develop the skills to a) recognize when this kind of misalignment exists and b) correct the problem by getting everyone on the same page, you will be in an excellent position to take on a leadership role in any project.
Fundamentally, this is an issue of communication. When discussing something abstract and multidimensional like a project, it is very easy for misalignment and misunderstanding to arise. This is especially true when there are multiple stakeholders, when the project becomes large and complex, and when it’s not feasible to have frequent meetings.
In the Project Lab, we encourage students to use several skills and tools that we find are very helpful to ideally avoid these issues from arising, or to correct them when they do. We hope you will use all of the skills and we will work with you to determine which components are most useful to describe your project, and should thus be included in your proposal.
When you are discussing something complex, or when someone is trying to explain something to you or trying to communicate or share their thoughts with you, it can be very helpful to repeat back to them your understanding of what they have said. You should do this in good faith with the goal of reaching a common understanding. Example, “Okay, I think I’m starting to get this… do you mind if I repeat back to you what I think you said, but in my own words, and then you can let me know where I’m going wrong?”
You might be surprised by how many iterations it can take to reach a common understanding.
We will talk about structure a lot in capstone. There is no single definition of structure for a project, and each project is different. But it is almost always the case that a meeting, report, plan, schedule, budget or anything else related to a project can be improved with a bit of structure.
We will work with you to develop the structure of your project, but here are a few points that hopefully help explain how we think about structure:
In general, we’ll ask you to be aware of whether and how effectively you’ve communicated structure to your audience, prior to diving into details. Here’s a way to think about it: Providing your audience with structure before getting into details is like first explaining to them what the “bookshelf” looks like, and how major sections relate to each other. Then, when you start introducing details, your audience will know which shelf each detail goes on, how it connects to other details, etc. If you just start giving them lots of details, they’ll need to construct their own shelf or structure on the fly, and it might look very different from yours.
A picture is worth at least 1,000 words, and we will heavily emphasise visual communication in capstone.
Think carefully about how data can best be presented to facilitate analysis and understanding.
For plots, of course have clear labels (axes, series) with units, a title, and make sure you’re plotting on a relevant scale. If you have more than one plot, try to keep them all to the same scale for easy comparison. Even better: can you plot multiple series on the same plot? Consider adding labels, lines, transparent colour blocks, etc., to indicate important events (the interval during which the heater was on, for example).
For presenting numerical or text information, are you making a comparison between different items (two scientific cameras, for example)? Would presenting the data in a table make comparison easier than bullets?
In general, always ask yourself: “How can I make this better, more intuitive, more consistent, and easier to understand?”
How do you actually capture the size, structure, and content of a project? Different industries have different established systems like requirements documents, design history files, etc., but in the Project Lab we find that a simple “scope table” works well for most projects. (Note: we made up the term “scope table”, so don’t expect that others will understand if you use it… but feel free to spread the word.)
A scope table is just a simple way of breaking down the scope of your project into different “dimensions”, and then prioritizing what you plan to achieve in each of these dimensions. For example,
Dimension | Must have | Should have | Nice to have |
Sensitivity | 1 part per million | 0.5 ppm | 0.1 ppm |
Operating temperature range | -20 - 120 C | -20 - 150 C | -40 - 200 C |
Portability | Stationary, wall power | Portable, < 10 kg, 10 hr battery life | < 2 kg, 10 hr battery life |
User interface | (none) | LCD screen | iPhone app |
.... |
The scope table will allow everyone (especially your sponsor) to see, at a glance, the size of the project and the prioritization of various aspects. It is a very simple and useful communication tool to keep everyone on the same page.
The dimensions will be different for each project. In general, you want to capture the most important requirements or specifications that drive the overall scope. You want to be specific and precise, but you also want to keep the table small enough to be useful - ideally it can fit on one slide, at least in the early stages of planning. Note that the “portability” dimension includes both size and weight and power supply. It might be better to break this out as two separate dimensions, depending on the project.
[IN PROGRESS]
Each row captures a unique risk, with a short corresponding title or description. There are columns for risk (how likely is this to occur?), impact (how severe would it be if it occurred?), ability to mitigate (what can we do to fix this if it occurs?), and overall risk score, which is usually something like risk score = likelihood * impact / ability to mitigate. Colour coding the rows according to overall score is helpful, with red being high (risky) and green being low (resolved). Over time, the table should shift from red to green as you make progress.
[IN PROGRESS]
[IN PROGRESS]