Project Managers Should Think Like Startup Founders
Last updated: November 04, 2023 Read in fullscreen view
Recommended for you
- 02 Nov 2021
What is Terms of Reference (ToR)? - 18 Oct 2021 Key Elements to Ramping Up a Large Team
- 03 Apr 2022 Microsoft Solutions Framework (MSF)
- 19 Oct 2021 Software development life cycles
- 20 Jul 2022 Software Myths and Realities
By Ron Ashkenas
November 02, 2023
Havard Business Review
Ron Ashkenas is a coauthor of the Harvard Business Review Leader’s Handbook and a Partner Emeritus at Schaffer Consulting. His previous books include The Boundaryless Organization, The GE Work-Out, and Simply Effective.
Summary: Most project managers focus on planning and execution. But large projects rarely go in a straight line, and often that planning doesn’t take into account key assumptions, and the execution goes far in the wrong direction before the need for changes are recognized. Agile approaches don’t go far enough in solving this problem because they focus on pivoting quickly — being reactive — rather than avoiding the problems to begin with. The author, a strategic advisor to large firms, suggests that project leaders should think like startup founders instead, using the tools that have become common in that sector: a project canvas, customer development, and so forth. In doing so, project leaders can uncover and solve for some of the project’s biggest questions and risks first, before scaling to full execution.
In most organizations, projects are temporary endeavors to achieve a specific goal, such as implementing a system, launching a new product, or solving a customer problem; project managers lead teams to achieve these goals within an agreed timeframe and budget. As such, the skills that project managers are taught usually revolve around planning and execution: defining the work, identifying agreed-upon measures of success, constructing a workplan, mobilizing a team, marshalling resources, monitoring progress, and getting to the finish line.
This emphasis on planning and execution, however, belies a fundamental reality, which is that most large-scale projects — especially those that have a lot of uncertainty — do not proceed in a straight line like an engineering blueprint. As the boxer Mike Tyson once said, “Everyone has a plan until they get punched in the mouth.” At that point, planning falls apart, assumptions need to be revisited, and the project manager needs to adjust on the fly.
“Everyone has a plan until they get punched in the mouth.” - Mike Tyson
The new plan needs to deal with right now reality. There's no point thinking about training and strategy while you're being punched in the face.
In my work as an advisor to large organizations with large projects, I’ve seen that successful managers of complex projects with many unknowns do adjust over and over again — but they don’t just wait for the next punch. Like managers of startup enterprises, they start with the premise that most project goals are achieved through constant discovery and iteration, rather than through executing a set work plan. (So to be clear, I’m not talking about agile project management here — that approach is based on the idea of pivoting when things change or when there’s new information. Instead, project managers need to shift both their mindsets and planning processes to anticipate those changes and head off some of the need for constant pivoting.) As I’ll explain in this article, they can do that by incorporating several very useful tools from the startup world into their own processes.
When You Don’t Think Like a Startup
Let’s look first at how a typical project can flounder when the project manager focuses on execution without a startup mindset: A few years ago, I was consulting with a consumer-packaged food company that was growing rapidly through the acquisition of numerous brands. The CEO and CFO asked a senior IT leader to implement an enterprise financial reporting system that would capture the data from all of the brands and put them together in a way that reflected the performance of the company as a whole. The goal was for the system to be up and running within a year.
After agreeing on the specific reports that would be needed, the project manager selected a well-known enterprise software company and then put together a team of finance and IT people who would install the required finance modules for each brand organization. As such, this agile project was largely about software implementation — adjusting for the peculiarities of each brand, testing, training, running systems in parallel, debugging, and so on. After nine months, and a couple million dollars, the system went live and each brand was able to produce a similar set of reports — sales volumes, inventory, unit cost, and more. But each brand used different measures and definitions. Some used pounds, others measured in kilograms; some considered a unit to be a can or jar, while others defined units as cases, or pallets, and so forth. So, despite the fact that the software was implemented successfully, enterprise reporting was still a Tower of Babel and required an enormous amount of manual intervention to decode — leaving the company not much better off than before the project had launched.
In retrospect, it’s easy to say that the project manager should have realized that all of the brands had different measures and definitions. But uncovering and dealing with the differences across brands would have required that he employ very sophisticated skills of discovery, facilitation, negotiation, creation of a common vision, experimentation, and more. The actual systems implementation — which is what the project manager knew how to do — should have then been just a relatively small (although still important) aspect of the overall project.
A Startup Approach to Project Management
In short, taking this approach would have required the project manager to think like a startup leader, not just an implementor. And luckily, a very good and popular set of tools for startups is available from the work of Steve Blank and others. There are four tools in particular that are critical to project managers and can be tweaked for their purposes; in effect, these are:
- A project management canvas: A one-page document that describes the value proposition of the project, the various stakeholders, the possible partners, the resources that might be required, and the key work streams. Developing this document is a way of asking big, key questions up front, and also seeing how all of the pieces are meant to fit together. It’s tempting to just assume the answers and get moving on the project, especially if it has tight deadlines, but going through this process carefully allows assumptions and needs to be surfaced before the work gets going.
- A customer development process: Discussions of the canvas with as many potential stakeholders and partners as possible to find out how the potential project might help them, or how it will affect them.
- A minimum viable project: A small-scale experiment of the implementation to generate early results, more learning, and more buy-in.
- A scale-up strategy: A plan for building on the small experiment and moving towards broader implementation.
Using these tools can help a project manager move iteratively toward the project’s overall goal through successive stages of discovery, learning, testing, and scaling — rather than simply implementation.
Eventually, the project manager in the consumer products company I worked with did get to an iterative startup-like process, with some prodding from the CEO and consulting help from human resources. After realizing that the “common” reports were really not common across the enterprise, he organized a two-day workshop at headquarters for the finance heads of all the brand units. This was essentially a (time-compressed) customer-development session where everyone could express their views about what it would take to get to common metrics for financial reporting. The team also agreed on the first categories that would be reported in the common format (a sort of minimum viable project) by the next reporting period. The experience with this MVP then allowed the company to scale the effort over the subsequent six months and realize the goal of enterprise reporting, even if was accomplished late and with greater cost.
Right from the Beginning
Of course, taking this approach from the beginning is even better. Consider the case of a large, global pharmaceutical company that I consulted with not long ago: Over the years, the company had developed or licensed hundreds of targeted drugs, but many of them received little or no focus from the marketing and sales teams because the patient population for each was relatively narrow. But the drugs were still on patent and helpful to certain groups of patients. So the president of the commercial business asked one of his people to organize and manage a project that would generate additional revenue from these already-existing assets.
Rather than jumping immediately into implementation planning — for example, rushing to pick a product or two and assigning marketing resources to each — the project manager used her initial conversations with the commercial executive to explore the possible parameters of the project: The overall goals, key people who would need to be involved, questions that needed to be answered, possible resources required, suggested governance, and more — essentially, a project canvas.
She then shared this initial thinking back with the president who had commissioned the project, confirmed that the canvas was mostly correct, and then began a round of interviews with regional sales leaders, product marketing experts, financial and product analysts, and others. These “customer development” meetings addressed questions such as: Which of the products might have potential for helping more patients? What would be the financial impact of increasing sales in these products? What was preventing the sales force from concentrating on these products? What marketing materials would be needed? And so on.
As an outcome of the customer development meetings, the project manager now had a good working list of 20-25 products that had the potential for significantly more patient impact and sales. She also had a better picture of why these products were not being marketed and sold more effectively — some had simply been set aside because they were older, others didn’t have up-to-date marketing materials, for example.
To iterate towards a solution, the project leader pulled together a small cross-functional team which then created a minimum viable project, focused on product sales in one country. The MVP consisted of an analysis of the sales of these products in that country to identify the best products for additional focus, and then a half-day workshop for that country’s sales and marketing team. At the workshop, the team selected a few of the under-marketed products that they could market without diminishing their focus on the products they already were working on and set specific goals for increasing prescriptions for those drugs within 60 days. They also created a tailored plan for marketing assistance, collateral materials, and measurement tools to help them achieve these goals.
In a matter of weeks, the team saw a significant increase in prescriptions written for the targeted products in this country without reducing the sales of other products, so two other countries were then selected for a similar process, tailored to their markets. Doing this allowed the project team to scale their effort quickly and efficiently.
The rapid increase in the sales of these products reached into the hundreds of millions of dollars within a year, with more incremental sales added each year. In essence, the project team, by thinking like a startup, had created a startup business for the company. Obviously, this startup mentality might not be appropriate for all projects — particularly those that are straightforward and well-defined implementation efforts. But for most projects where there is uncertainty and ambiguity about what’s to be achieved, or how to achieve it, taking a startup approach can make all the difference. While it isn’t easy and will require constant iteration and discovery, it’s far better than waiting to get punched in the mouth.
Explore more on these topics
Guest Blogging: The Definitive Guide
