Congratulations – you, as an external project management consultant, have been asked to run a project for your customer. Now what? How do you as fast as possible get a firm grip on the steering wheel? Are there some fairly generic approach to get your project started?
Let’s define some assumptions, setting the context for this post:
- your project is classified as a classic/agile project (see the illustration to the right) based on ad-hoc project teams allocated from the functional line, and being measured on the ability to deliver output. In contrast you’ll find the “Product Innovation” segment based on stable cross-functional product teams being empowered to discover the best solution to (hard) business / customer problems and held accountable for outcome. Many of the previous posts, like this one, have addressed exactly that product innovation context.
- your customer has a big home-grown project process / governance universe, probably to some degree inspired by a mix of frameworks / models like Scrum, PRINCE2, Kanban, SAFe, Half Double, PMI, AgilePM, Six Sigma, ISO 9001 …
You do not, at least initially, have the luxury and time to deep-dive into the customer’s project process / governance universe. You need, as a project management professional, to bring your own experience and framework / model agnostic toolbox to get quickly started.
The aim for this post is thus to discuss a general approach for you to get your hands on the steering wheel as fast as possible.
At first glance this post might seem a bit long, but trust me, this is nothing compared to reading e.g., the PRINCE2 bible + the Scrum bible + the Kanban bible + ISO 9001 + … have e.g., a look at some of my inspirational sources.
The high-level structure
The classic errors seen with less experienced project managers are (also)
- A fixation on and dependencies of the process universe making it hard to get quickly started
- Too quickly starting execution before having a solid overview
In contrast, the experienced project manager is able to act independently, building the overview before entering execution. I’ve found this generic high-level structure effective:
Understand the fundamentals
Here is a list of fundamental elements that I’ve experienced as a solid starting-point:
- Purpose
- End-goal and (hierarchy of) objectives
- As-is situation
- Key stakeholders
- Significant challenges, risks and opportunities
- Top-level milestones and dependencies
- Business Case
- Compliance requirements on processes and tools
- Available competences and capacity
Purpose
“Why are we doing this project – what is the rationale?” is the most important question at all. The answer to the question is what releases the energy and engagement in all of us in the project. We’re all only humans, and without a clear purpose / rationale, we’re simply not able to feel engaged (sadly I’ve experienced far too many projects fail exactly because of an unclear purpose).
Formulating a sharp, crisp and engaging purpose is not easy and close to an art-form. Example-features of a well-formulated purpose:
- It is simple, easy to understand, remember and explain for others
- Aim for no more than three bullets thus avoiding a long shopping list
- The purpose must support a clear scoping of the project thus “only” cover the rationale – not more
- The purpose must express a business rationale / benefit for the project owner and thus not “only” a technical solution
- The purpose must be held within the influence-sphere of the project
- If relevant the purpose could describe the delta from old to new
The principle is: keep the purpose short, sweet and to the point.
End-goal and (hierarchy of) objectives
Another classic error seen among less experienced project managers is the reactive activity planning-forward mindset. They’ll quickly loose sight of the real end-goal.
All professional project managers need to have a time-machine in the garage and be fully capable of providing guided tours in it. The governing principle is start with the end making sure that the end-goal will drag us as a future magnet in the right direction; also in the case where we’ve taken a de-tour from the direct path to the end-goal.
Being the facilitator and time-travel guide, you’ll bring relevant stakeholders to the point in time where you’ve just closed the project. You invite your passengers to step-out, asking them to describe what they see.
Your aim is to have the time-travelers provide a rich situational description of not only what they observe, but also what they note as especially important and/or successful. Using a Six Sigma term you’ll identify CTQ (Critical To Quality) areas.
This rich situational description of your end-goal will act as the top-node / project vision in your “hierarchy-of-objectives” or “product-breakdown-structure” (a term used in e.g., PRINCE2).
Being the facilitator / time-travel guide you can use e.g., the notion of the Whole Product 
to inspire and challenge your travelers. Example:
- the generic product is some IT-functionality enabling your organization do something new / better than before
- the expected product, adds to the generic product in three areas
- experience
- enrichment
- extensibility
- each of the expected product areas further details what becomes the whole product
- experience
- training
- user support / superusers
- on-line documentation and business processes
- self-service functionality
- enrichment
- installation, configuration and operation
- formal quality certification
- 3rd party functionality integration
- extensibility
- open APIs enabling an API economy
- protection of Intellectual Property Rights
- experience
Some of the features of the Whole Product might not be immediately obvious, but rest assure, if you do not deliver on them, then they’ll become very visible in a bad way at a later stage.
Your job is now to take your time-travelers gradually back in time until reaching the as-is situation. For each step you’ll be asking
- What objectives had to be met / product delivery made before the situation this point in time?
This way you’ll progressively build a hierarchy of objectives. You and your time-travelers will most likely learn new insights in the process requiring you to go back and forth in time. No worries – this is perfectly normal.
What you end-up with is a hierarchy-of-objectives unfolding the objectives to be met for you to reach the end-goal. This hierarchy-of-objectives is valuable for a number of reasons e.g.,
- It is a strong communications tool across stakeholders keeping us all on the same page
- It is a strong basis for your planning
Note that we at this point in time “only” talk objectives – not the detailed requirements or the activities needed to meet these objectives. You can think of the hierarchy-of-objectives as the naked tree. Later on we’ll supply the leaves being the activities.
The principle is: start with the end and do not talk detailed requirements and activities before having understood the objective(s).
As-is situation
As indicated under Purpose, a project’s main rationale might be to bring the company from an as-is situation to a future situation. In that case we also need to understand the as-is situation.
The as-is situation can be everything from being lean, mean and well-functioning to a de-railed situation needing a fire-extinguisher.
The principle is: if the purpose of your project is to bridge the gap between a future to-be situation and the current as-is, then you (also) need to understand the latter
Key stakeholders
The most important stakeholder is the Project Owner being the chairman of the steering committee. If your customer is thinking in PRINCE2 terms, your steering committee will in addition have a Senior User and one or more Senior Suppliers. It might also happen that your customer is not having a structured approach to steering committees in which case you need to advice / coach on the subject.
A project without a strong and clear owner is doomed. If the project does not have an business owner, then why run the project?
You need to understand all your (most important) stakeholders – not “only” the steering committee – and have an initial dialogue with them.
The principle is: always understand and maintain a dialogue with your customer and stakeholders
Significant challenges, risks and opportunities
Through the initial dialogue with your stakeholders, you’ll start building an understanding of challenges and risks needing active management. Do not forget also to seek opportunities for your project to benefit from.
In the international quality standard ISO 9001:2015 you’ll find the notion of Risk-basted Thinking [RBT]. Even if your customer’s processes are not subject to a ISO 9001:2015 certification, the mindset behind RBT is widely applicable.
Def. [Risk] “the effect of uncertainty” – might be positive or negative comparted to what as intended.
Def. [Opportunity] “a set of circumstances which makes it possible to do something” – taking or not taking an opportunity represents different levels of risk. An opportunity is thus not merely the positive side of risk.
- RBT will weigh the risks from proceeding or not proceeding with an opportunity or curse of action and decide on implementing mitigations or not. The point: prevention is better than cure.
- RBT is an attempt to balance between insufficient diligence and strict formal Risk Management (seen in e.g., ISO13485 Medical Devices).
- Resulting from RBT is a clear decision on Accept (take risk), Avoid (not proceeding), Mitigated (make the risk more acceptable).
ISO 9001:2015
A lot of different approaches exist to uncover risks in a project. One particular effective approach is called pre-mortem. Using your time-machine, you’ll jump to a point in time where your project unfortunately went totally off-rails, now asking: what de-railed the project making it go over the cliff?
The answers to this question generates (potential) risk-areas.
The principle is: promote Risk-Based Thinking throughout the whole project
Top-level milestones and dependencies
Maybe your project is part of a larger program with a milestone plan defined across the included projects. You of course need to understand such a plan.
In addition, you need to understand (initially on a high level) what natural milestones exist in your project and how the dependencies are between these milestones. Yes – you’re right. The work done with the hierarchy-of-objectives is a great help here.
You might be thinking “hey – I’m actually expecting (approach strategy) this project to be run as a highly Agile project – why would I care about a milestone plan?” My experience is that a milestone plan modelled with (hard) dependencies is a very helpful tool also when doing Agile planning; e.g., in the prioritization of the Product Backlog.
Should your customer’s formal project process requirements prescribe a stage/gate model, the milestone-thinking is again very helpful.
The principle is: without too much detailing, a milestone plan modeling the higher-level dependencies helps you plan, maintain and communicate the big picture
Business Case
Some customers have a very strong and mature use of the Business Case being the center-piece around which the project evolves. In e.g., PRINCE2 the Business Case is such a center-piece with the Product Owner, owning and being accountable for it.
Other customers have a more vague documentation of the business rationale, but in all circumstances you need to seek and understand whatever business-rationale documentation exists for your project.
Well, in some projects is does not exist al all – yet. It might be part of your initial assignment to drive the development of such a business rationale.
The principle is: always understand the business rationale behind your project – if no clear rationale exist, do not run the project
Compliance requirements on processes and tools
Your customer will, with 99% certainty, have some form of defined project- and governance process. You need to understand the level of mandatory prescriptions for you and the project to comply to.
Your customer might also have a suite of (IT) tools, some of which are mandatory to use.
Make sure to get an understanding of these requirements (and opportunities) as fast as possible. You do not want to invest a lot of time and energy travelling down a blind road.
The principle is: make sure as fast as possible to understand the formal constraints (and opportunities) on processes and tools
Available competences and capacity
Depending on when you’re assigned to the project there might / might not exist an overview of competences and capacity being made available to you in the project.
Make sure to be able to staff an initial core team together with whom you’ll bootstrap the plan for the project.
The principle is: start small with a strong core team and expand from there
Approach strategy
With the insights collected above in The Fundamentals, you have a solid basis on which to define your approach strategy. You can think of the approach strategy as your overall plan for how to get from the as-is situation to your end-goal … your project vision (remember our time-travel) … in the way minimizing risk and optimizing business value.
Here are some inspirational features for an efficient approach strategy:
- Your strategy is based on a solid understand of the given context (The Fundamentals above)
- Your strategy will apply a Risk-Based Thinking mindset in a quest to prevent risks vs curing occured risks
- Your strategy must be easy to understand and communicate
This can be a bit abstract, so let’s bring it down to earth and define an example-context and some strategy-challenges with in it.
Example context
Let’s assume that your customer is a successful high-tech product company with a global footprint. Your customer innovates and produces a range of multidisciplinary – a combination of high-precision mechanics, hardware (power), electronics, embedded software and application software – products.
Your customer is highly focused on the continuous improvement of the end-to-end business agility and has identified a need for a more integrated PLM (Product Lifecycle Management) / configuration management. This is much more than “just” an implementation of some IT-functionality. It is also very much about business processes and the humans using them … globally.
Just to give you an idea on, how high the bar can be set, this previous post gave a glimpse into the extreme innovation and manufacturing world at Tesla.
Your customer has the three core ISO HLS certifications 9001:2015, 14001:2015 and 45001:2018 plus a number of other international certifications. During your getting “The Fundamentals” right, you of course also need to understand, if your project has a dependency on these certifications (in this case most likely the business processes in the company’s QMS – Quality Management System). Think “The Whole Product”.
Strategy challenge #1
Challenge: No one is able up-front fully to specify the requirements to be met. In fact – the best solutions to the business problems remain to be discovered.
Strategy element #1: This is a classic example of an experimentation strategy. We cannot (because we do not know it) provide the project team with a solution to develop. What we can do is task the project team with (hard) business problems for which the team needs discover the best solution. Our previously defined hierarchy-of-objectives comes-in handy again.
Teams trained in and experienced with hypothesis-formulation and experimentation-design to test the hypothesis, can work very efficiently.
The principle is: fail fast – learn fast. Such fast feed-back loops are highly effective and helps us validate a solution before investing efforts in its implementation.
Strategy challenge #2
Challenge: (Some of) your stakeholders are impatient to see concrete results, fast and continuously.
Strategy element #2: We clearly need to show results on a continuous basis. A “big-bang waterfall” approach is not an option. The IT-part of the project thus calls for an Agile approach thinking in terms on “vertical slices”.
In the “old days”, we would work with “horizontal slices” e.g., building the server-layer, then the middle-ware and finally the user-application layer. It would thus take a long time before the users could see anything.
As illustrated here, the “vertical slicing” can be seen as a cake (the illustration to the right). When e.g., tasked with “Pay order with credit-card”, the “full-stack” team will work simultaneously on “Data Layer”, “Middleware” and “Web UI” to produce and deliver the ability to pay order with credit-card.
Not only will we satisfy a need to show continuous progress and delivery of functionality. Equally important we’ve established the important feedback loop enabling us to get feedback from the stakeholders and have that feedback / learning integrated in the rest of the project.
For this to work, we need a working CI/CD pipeline.
The principle is: slice your architecture in a way enabling you to deliver working functionality after each sprint
Strategy challenge #3
Challenge: Many users tend to be skeptical – we’re doing ok today, so why this change (we’re getting tired of all these constant changes).
Strategy element #3: It is only human asking the simple question “what’s in it for me?”. You can of course try intellectually to argue, why the to-be situation is attractive and creates meaning. With the words of Daniel Kahneman, you would be talking to the slow-thinking type 2 operating system in the brain making-up 2% of all our thinking. The remaining 98% is what Kahneman calls the fast-thinking type 1 operating system.
The challenge for achieving sustainable change, is to anchor the to-be situation in the type 1 operating system through involvement and action-training.
The principle is: make change concrete and de-mystified through involvement and action-training
Strategy challenge #4
Challenge: The project maturity is low (well-below CMMI-2), with parts of the organization in reality not understanding the nature of a project and what it means to be involved in a project. The notion of “Agile” is definitely not broadly known or appreciated.
This lack of project maturity / professionalism has historically been manifested in e.g., activity plans without clear objectives and strategic thinking … or put into other words: lack of an approach strategy.
Strategy element #4: The way it is, is the way it is. Respect the status and do not expect or ask the organization to perform on a level currently unreachable to it. Invest some time in understanding where the biggest pains / challenges are in the organizations project execution ability, and gently nudge it forward with carefully chosen doses of improvement initiatives to the level making it valuable for your specific project.
The principle is: always understand where the organization currently is and improve from here to the extent it makes a profitable Business Case for the specific project
Strategy challenge #5
Challenge: Even before you enter the project, it is under a significant time-pressure with a hard deadline. If this deadline is not met, the factory’s supply-chain will break.
Strategy element #5: All experience says that allocating more people to a project in this situation, only makes it worse. The only two viable strategies mitigating the risk of missing the hard deadline are
- Scope reduction
- More work done in parallel
The nature of your project and its organization will determine the appropriate course of action.
The principle is: mitigate the situation with the project team at hand – do not try to force more people into the project
Baseline planning
Having understood the fundamentals and having defined a situational approach strategy, you are ready to base-line your plan. How you do that is highly dependent on your approach strategy.
Transparent execution
No matter where your project is on the scale from fully classic big-up-front-specification Waterfall to pure Agile … or a mix in-between – you need to ensure transparency in the execution. How you do it and what tools you use is again highly dependent on your approach strategy.
Wrap-up
The core message is:
Always have an approach strategy derived from the context in which your project exists.
Update
This update to the original post suggests the use of visual communication, enabling you to convey the big picture on one page. Inspired by The Grove‘s Graphical Game Plan [GGP] this can help (and force) you to communicate the essence of your project:
