Here are some examples about the type of strategic analysis we've done. Click on an item if you would like to read more about it.
We believe that one of the ways in which an expert should be judged is the degree to which they can explain their ideas and methods clearly. Experts don't fear challenge or criticism, they welcome the opportunity to explain their ideas more fully and learn from the experiences and perspectives of others. We hope you will find this material interesting. This isn't the full detail of our approach, it's meant to help us have a conversation.
Why Use Us For Project Management?
Project management is often a task that businesses prefer to keep internally. The reason to consider involving an outside party is that sometimes project management takes up too many of your best people. You want their thoughts and energy engaged on winning new customers or transforming the business but instead they are focused on making sure that the project is on track and using their expertise to monitor and cajole the rest of the project team rather than adding value to your business.
“Deliver with quality and involve the whole team”
We bring organisation, creativity and a focus on delivery. We know how to plan, even the dreaded task of thinking about how things might go wrong (and then how to get back on track again). We deliver with quality and involve the whole team. We keep the project team and key stakeholders up to date on project status and provide clear direction on what help is required.
Project management often sounds so simple in concept: decide what you are trying to achieve, work out who needs to do what, create the timeline, communicate the plan clearly, secure resources and then track delivery until everything is completed on time, on budget and to widespread public and critical acclaim. For some reason, it doesn’t always work out that way. The problems below seem familiar…
The intent of the project isn’t clearly understood
What goes wrong? It isn’t often that no one has any idea what the purpose and end goals of a project is but frequently it means different things to different people or it is not understood by every single group who will deliver or champion it. Without clarity, the team will not develop a shared intuitive understanding of the project or the balance of trade-offs that best meet the customer need. This becomes a big problem when making decisions under pressure and evaluating the best way to get the project back on track. What if a shortcut crosses some unspoken project red lines by mistake?
“There could be additional voices we need to listen to”
The solution -- we work with the various team members to identify the extended group responsible for project delivery (this doesn’t always show up on the organisation chart, for instance those with direct delivery responsibility may not control their resources -- there could be additional voices we need to listen to). We check the understanding of these team members in terms of their own frame of reference. Inviting them to ask and think about how much this will be like Project Icarus (we don’t always get to choose the project names).
The people responsible don’t feel accountable
What goes wrong? People don’t do what was expected of them. The project descends into chaos or the project management team must work overtime to try and deal with the fallout of project elements being delivered late or over budget by team members who do not see it as their problem or are making independent decisions about how this fits with their other priorities.
“Understand the focus and priorities of the various teams”
The solution -- we develop the responsibilities for the project and we test them. We find tasks that we can get underway with quickly, or surrogate tasks in other projects, that can help us to understand the focus and priorities of the various teams. Where we find a problem, we discuss it and uncover the source of the underlying reason that the project work is being de-prioritised.
The unexpected just happened
What goes wrong? At the heart of every project lies a trilemma of cost, quality and deadline. If there is no deadline, then we aren’t managing a project -- it’s a process (we can help with improving processes too). Frequently the plan either over-simplified the problem or was based on what happened last time. Planning based on experience is a good move but without questioning the exact lessons learned we can fall into the trap of creating a plan that deals with the unique problems of the last project and fails to anticipate what will happen this time.
“The worst case plan simply takes too long and costs too much to get approved”
On the surface there seems to be an obvious answer: plan for the worst case. Unfortunately, this approach normally fails the project approval stage. Why? The worst case plan simply takes too long and costs too much to get approved -- although it seems detailed and thorough it is lenient on the project management team (because it provides for everything to go wrong and yet the project still to be okay). If this is our approach then at the very least we can save cost by ditching the project managers -- we’ve built in enough cost and time to make them redundant!
The solution -- We need to plan based on the recurring elements of prior projects and then focus on what does not recur. What happens? When is it found? What does it cost to resolve it? How long does it take to fix? By answering these questions we can build a challenging test plan and a contingency in terms of time and money. It often sounds over the top but it is how we move back from worst case planning to something that is affordable and deliverable.
I’m spending more time reporting than I am managing
Sponsorship and senior management interest is very welcome and can often be a great benefit to the project. The problem is that there is often a flip side. Having supported a project, people then want to see if it is on track. On complex projects, some element normally is off track and then people want to know why it is wrong, who is to blame, how it will get fixed and how long that will take. The project managers can find themselves running around in circles creating new reports for the different constituents and trying to create historic tracking for things they’ve only just started measuring.
“We don’t want an exhaustive set of metrics and over-bearing data gathering”
The solution -- communication must be planned in at the start of the project. The analysis of the project flow and potential issues should have provided a list of the things that can go wrong and this is the foundation of project tracking. Getting the right balance is difficult because we don’t want an exhaustive set of metrics and over-bearing data gathering. Thinking through how we would report things if they went wrong leads us to understanding how to present what the project must measure to ensure success. We can then run a simple but comprehensive assessment of project health and historic problem tracking on the key issues and test that key stakeholders are happy with it before we get started.