Project Management from the Present
Updated: Mar 24, 2020
I must warn you; this is not a blog about how to navigate the chaos that COVID-19 has potentially thrown your project into. In fact, statistics indicate that most large complex transformation projects are either on their way to failing or paralyzed because they cannot find the right path to go down, without a pandemic.
My theory for why this is relates to how projects generally deal with uncertainty by pretending that it does not exist. And this pretense is a biproduct of what companies generally have been indoctrinated to prioritize: predictability, measurability, meeting targets, and expecting employees and consultants to “perform” like the experts they are paid to be.
In light of the pandemic, project teams and business sponsors will inevitably have to grapple with new levels of uncertainty, and once they pull themselves out of chaos, I hope these tips can be useful to navigate from the present state.
Rooted heavily in the Cynefin Framework, created by Dave Snowden, my goal is to describe briefly, what applying complex adaptive systems theory to your projects can look like, in terms that will hopefully resonate with many project managers. It is not meant to be a prescriptive method, so I hope you will not interpret as such.
Defining the AS IS state
This is usually described at the start of a project by the business function who wants a change and there is usually a “burning platform” to replace &/or new tech that is desired.
Tip: If you are having a major problem or set back it can be good to do an “AS IS” assessment mid project to re-scope/plan the way forward from the new context. But the below also applies to doing an AS IS at the beginning of a project.
If you put extra work in at this phase to accurately describe the current context from the joint perspective of your entire stakeholder community, it will pay off in the long run. The goal here should be to create a (mostly) shared reality, and this will as an effect, improve stakeholder buy in. Note: Not each person needs to be asked, but representation from the entire spectrum of relevant variety.
How: Use an objective facilitator to conduct a workshop that encourages open communication and constructive collisions to construct a shared reality.
Designing the TO BE State
Like the AS IS, this is usually described by the business function who wants the change. The solution is often prescribed and created by experts based on best practice.
Tip: Develop the desired future state together with the key stakeholders & capture the benefits the group wants to achieve, including the ones that are not measured in numbers. The more predictable parts of the solution can be described here, but only after the requirements have been clearly understood. (For exampe, don’t say you want AI and then work your way backwards, say what you want to be able to do and possibly AI will be the solution).
How: Objectivity is key here. It is of utmost importance that preference and politics does not contaminate this element. Use experts to help guide the conversation and explain what is possible, but do not let them steer you towards the solution they recommend by promising it’s “best practice”. If you are running an RFP, it is highly recommended to have an objective partner to assist.
Note: For the later detailed solution development, Agile works well but you do not have to wait until your organization has an “Agile transformation” and everyone gets certified to do so. Following the basic principles and having your developers and business teams work closely together will get you further than “perfecting” your Agile structure.
Business Case / Benefits
These are usually quantitative data focused: cost/ROI, headcount before/after, which KPIs will improve and by how much.
Tip: Include the benefits that are hoped for but cannot be quantified and/or predicted. These might be the most important ones. Leaders should ensure the benefits align with the strategy and accept taking innovative approaches to achieve them as long as they are measured along the way and adapted to stay on the right path.
How: Design both quantitative measures and qualitative measures for business benefits. For unpredictable elements, identify safe to fail experiments to run, and monitor them along the way to either keep doing, stop, or change. So often I see the qualitative parts left out because they are considered too subjective. But this is often how projects fail: they “successfully” “go live” and check off all the green boxes, but the business doesn’t understand or use the system, so essentially gets no benefits from the latest IT implementation.
Project KPIs (Time, Cost, Quality)
Generally focusing on time, cost and “quality”, most projects also measure their own success based purely on numbers. In many cases “quality” is reduced to testing activities in which the quality of the same can be questionable, as long as the cases are run and passed.
Tip: As the name indicates, you cannot measure quality by only looking at quantity. In order to not only ensure delivering business benefits from projects, but also to ensure running successful projects, qualitative data needs to be captured.
How: Monitoring quality involves developing what some would consider “soft skills” within your project team. This includes adopting a learning mindset, listening to understand, becoming aware of unconscious biases, reducing binary thinking, practicing cognitive diversity, asking questions you don’t think you know the answer to, etc.
You can also measure qualitative things through monitoring patterns instead of numbers. There are tools on the market to assist with this. I personally work with the narrative based tool, Sensemaker, created by Cognitive Edge, and the Danish tech start up product, Qvest, which is driven by democratizing questions.
It is critical to understanding that the most complex and nuanced parts of your project’s performance are often not reflected in the data most frequently reported on in project dashboard slides.
Project managers generally use a spreadsheet or PMO system to capture risk, likelihood, mitigation (if any) and person responsible.
Tip: It doesn’t matter which tool you use; it is the ability to distinguish things that need to be mitigated from the “noise” that matters. Almost all failed projects and disasters have weak signals that could indicate a looming failure that go unnoticed. Those weak signals need to be captured, recognized and mitigated.
How: Often, the most critical things do not fit into the quantifiable realm being measured, so they are labelled as “noise” and not taken seriously. Instead, “noise”, “cynics”, “elephants in the room” & “whack-a-mole topics” that keep coming up, need to be confronted head on by the requisite variety of involved project members & stakeholders, NOT assigned to one expert to handle.
Most often a team within the project identifies stakeholders and maps their perspectives out in order to strategize about how to convince them to change. Along with this goes training, communication, and if lucky, a business impact analysis that targets what users might experience when the change occurs.
Tip: This is possibly the area that needs the most drastic change. If you want to convince people to join you, you need to invite them to join you. And do not expect to make one sudden change from an AS IS state to a TO BE state; rather, build up change adaptively, experimenting about what works and does not work along the way.
How: Instead of speculating what stakeholder opinions are, ask them. Involve them from the beginning. Don’t make rigid templates that do not work for their process and convince yourself that their resistance is purely motivated by fear of change. Give them some credit; learn from them. Design for them. This process should iterate through various safe to fail experiments, finding out what works to change the behavior.
Usually nonexistent as a formal practice.
Tip: Accept from the beginning that things are not predictable and will not remain static, and create a decision log. Record decisions made along the way and use it to frame decisions that need to be made by whatever governing body there is in your project. Formalizing decisions helps to keep the project moving, keep the shared reality alive, and serves as a reminder to your future self about the context in which you made a past decision (when it potentially seems stupid later).
How: Decisions can be outputs of risk mitigations or safe to fail experiment creation/results (continue/stop/change), among other things. When facing a complex one, ensure to open the input variation and include relevant qualitative data.