Later this year, I'll be releasing my second book on project delivery. While we don't have a title at this point, it is going to focus on the idea of "Project Dynamics".
Project Dynamics is the idea that human and customer behavior within a project environment is somewhat predictable. What I mean is, you can infer a lot about how a project will end, simply by studying the way in which the project looks, feels, and operates.
An example of this is when we identify that a customer's project sponsor is not attending weekly project update meetings. Even PMI has identified that sponsor engagement is one of the most critical factors for a project to be successful. But if we can identify that active sponsor engagement is missing from either the customer or the service provider's team then we know that the project is running a gauntlet.
If a PS Manager can identify project dynamics that are occurring and putting the project at risk, then the manager can help the project team keep the project on track by proactively escalating issues. Proactively sending an email to the customer's project sponsor asking them to acknowledge that their absence from critical project decision meetings is implying their acceptance of what has been agreed thus far is a great way to stir them into action. The kind of action that only serves to benefit the project given their status as the "Acceptor" of the engagement.
This proactive review of a project should also focus on the service provider's ability to operate the project effectively. While I tend to point fingers at customers first when it comes to a lack of proper project engagement, it is often the service provider who goes missing if the customer is present and engaged. PS Managers have a habit of becoming Armchair Quarterbacks for their projects rather than active sponsors. In other words, we need "Project Managers", not "Project Managers". I've had PS Managers complain about the overhead that proper project sponsorship creates for them, but my response is always the same, "What else are you doing that is more important than making sure your current portfolio of projects make as much money as possible while delighting the customer?"
Yes, hiring is important. Yes, getting the invoices out is important. But none of them are more important than making sure projects are successful. Your eagerness to get involved will be reciprocated by your team regardless of how you do it. If you are reluctant to get involved, then don't expect your team to care too much about those projects on your behalf. Why would they, if you don't get involved? But if you do actively get engaged, then your eagerness will be echoed.
More importantly, be a servant leader. Get involved in your project portfolio by saying, "How can I help make this project more successful?" Use your experience to identify proactive steps that might head off worrying signs that you have seen on other projects. If a customer is demonstrating a lack of accountability, call it out and ask, "How can we help get this resolved?"
Overall, this is a simple equation. The effort you put in as a PS Manager as the sponsor of your projects will be returned to you in profit and customer references. On the other hand, if you ignore your projects, they will head out onto the mountain only to become lost and require rescuing.
**Enjoy what you're reading? Feel free to forward to your colleagues!**
On Belay
The Double-Edged SoW
In recent discussions with customers, we have identified how flawed our belief can be when it comes to the role of the SOW. We long for the SOW to give our project guardrails that we can follow. A project's limited budget and the customer's need to achieve an outcome means that we look to the SOW for answers that it does not have.
We ask it to tell us everything we need to build, so that we can have confidence that the budget is adequate. We look to the SOW to explain to the customer the true depth of complexity it needs to understand before it can help us effectively achieve an outcome. It does neither of those things and as a result, when it ultimately fails to provide, we feel lost and betrayed by the SOW.
My suggestion is that we release the SOW from these unrealistic expectations. Yes, it is a binding contract, but yes it is also misinformed. Hence we need to embrace both its legally binding intent but also its lack of informed complexity by having the confidence to simply say, "I've got this". We have to be prepared to argue for the SOW as much as against it. We need to place the document on both a pedestal as well as admonish its misalignment. We must execute the project to the SOW and away from it depending on the situation. Learning to strike this balance is key to delivering successful projects.
As a PS Manager we set the tone for how our team will perform in the field. If we make the SOW an infallible guide then our teams will follow it...to their detriment. I've found projects drifting in the abyss of project space and time simply because of SOW requirements that meant one thing at signing but suddenly became something else entirely once the true complexity of the project was discovered. This is blind devotion that only results in damage to the project's ultimate success.
Likewise, we can't just disregard the SOW. It does form the basis of how the work we are doing will be considered complete. If we ignore it, we hand the customer a raft of ways to hold us accountable for the things it contains that were not delivered. This makes obtaining acceptance virtually impossible.
Hence the role of a manager is to help the team strike that delicate balance. "What does the SOW say?" is a great question provided it is also balanced with, "Why would we do that?" or "Has the meaning of the SOW changed since it was written?" Our ability as managers to handle the ambiguity created by SOW governance will set the tone for how our teams deal with it. If we teach our team to respect the enforceability of the SOW while also challenging its integrity we give ourselves the best chance of having projects travel along the right path.
Free Climbing
Proaction in Action
What are the issues that we can proactively identify that might lead a project astray?
While we have developed a library of items over the years, what I find interesting about this concept is that every time I work through them with a client, we identify one that I've never thought of. So let's take a look at each project phase and just look at one proactive assessment that we can use to drive our behavior.
The first pre-project assessment that we can make is whether or not the customer's project sponsor is going to attend kickoff. Everyone else within the customer and service provider's teams has an imperfect copy of what the customer's project sponsor has told them. Having this person missing at the project's kickoff is tantamount to starting off in the wrong direction. At some point, a realignment will be necessary and that will cost margin and customer satisfaction. It is better to proactively avoid this impact by asking the customer's sponsor to acknowledge the need for their attendance and the likely consequences if they do not attend.
A dynamic that occurs during design is the customer's ability to make decisions. The customer needs to be able to both understand its own objectives while also synthesizing the varying ways in which the product can (and may not) help them achieve those outcomes. A proactive assessment we can make during this stage is whether the customer is making these decisions in accordance with the projects desire rate of progress. If the customer is struggling to make decisions then a signed design document within this stage's budget is unlikely. A proactive escalation may be needed to get the customer to bring in someone who can make these decisions faster. Another might be to simplify the stakeholder decision making process or possibly we can remove the "decision by committee" culture. While we, as the service provider, must take responsibility to accurately inform the customer of their choices, we must also hold them accountable to make those choices within the time constraints of the project or accept that taking longer to investigate their options will increase costs. The sooner we do this, the more likely it is that the customer will accept the natural consequences of the situation.
During the build stage an important proactive assessment is the customer's ability to establish a proposed operational framework for the new solution. Have they identified the people that will own the solution once it goes live? Are those people trained? Are they aware of the current environment? Are they ready to start testing? All of these dynamics influence how smoothly, or not, the testing stage will be executed. Another dynamic I focus on is the customer's ability to define the test scripts required to validate the solution during the testing stage. This tends to mirror the assessment I mentioned in the design stage. If a customer is capable of clearly articulating what it wants then they are usually also capable of writing decisive test scripts (and vice versa).
A dynamic to be aware of in testing is the customer's willingness to accept the product's functionality. For many customers, the testing stage is a real, "Aha!" moment. Despite the amount of effort that has gone into using iterations to show them the way the product might work, it is only when the product is fully baked that the reality of the functionality gaps begin to sink in. This again points to the need for an engaged team of stakeholders to make decisions. This is not just the customer's project sponsor, but everyone that is involved in the project. Whenever the product doesn't do what the customer wants, the question is, "Can we change that?" Even if the answer is "yes", we don't have the budget to discuss all of them in detail let alone actually go back and change them all. There needs to be a give and take in this phase like no other in project delivery. Here, we will win some and we will lose some, but what's important is the big picture of project profitability and customer reference. At this stage, if we have preserved project margin, it is a great time to spend a little bit of it to maintain the customer's excitement about the solution.
Hopefully this quick summary of how we can use proactivity as a way to keep projects on track has given you some ideas on how you might apply your own thinking to your projects. The general idea is that by knowing the challenges to avoid, then maybe we can identify the root causes. It's important to escalate those issues because they have a tendency to create larger problems.
Join our Summit newsletter group on LinkedIn and let us know how your firm has implemented and managed PS operational issues.
A new segment in the newsletter is the review of a resource that might be of benefit to other managers. Today's review is of Ray Dalio's "Principles: Life & Work". While you may think I'd read this book before writing my own principles, the sad fact is that I didn't. That said, I'm still happy that I've found it as I'm a big fan of how Ray has put this book together. What I like about this book is both its simplicity but also the comprehensive nature in which it describes every aspect that is covered. To be honest, it touts a series of views that I believe we have allowed to atrophy over recent times.
Ray separates the principles that he believes are the key to living a successful life from those that have helped him have a successful career. By separating life and work principles, Ray brings back a timeless balance between successful working and living.
The book is full of frameworks that can be deployed for a range of subjects but the most detailed frameworks are those in the work principles. They provide managers with some of the most comprehensive guidance I've ever seen for managers.
This is not a book from an author looking to use it as a retirement plan but a book about doing things the right way. It represents the lost art of structuring a life's worth of knowledge into a book from which we can all learn. We give it 4.5 stars out of 5.
If you have a book recommendation let us know at summit@psprinciples.com
PS Principles LLC, Prospect Ave, Park Ridge, IL 60068, USA, +1 (650) 731-0001
