Patience is not the art of waiting; it is rather the art of timing.
The saying above was something I came across in reading leadership focused material and was attributed to “anonymous”. Immediately I thought that if I’d come up with this saying, I would surely want to take credit for it as it immediately resonated with me. My personality type is such that I’m not good at waiting for anything – stoplights, family, deliverables, people in general. But in reflection it was something that revolutionized my perspective on patience.
Most Project Managers I’ve worked with are impatient by nature. We are a group of people that are recognized primarily because we get things done. Many times I’ve heard a senior leader, frustrated with the pace of delivery on a business or technical initiative, say something like “do we have a project manager on it?”, or “where is the project manager”, or “what is that project manager doing!”. That indicates to me that in their moment of frustration they want to turn to someone in their group to hold accountable for “getting things done”. We are those people. It’s difficult for me to think of a successful project manager that doesn’t also have the reputation to be someone to turn to “get things done”. This is a well won reputation and the stronger the reputation the more valuable the project manager.
At the same time, we know there are negative outcomes from our desires to push hard on deliverables. We can become an overbearing tyrant to the team as we push on tight schedules, or we may run fast to find that we’re delivering the wrong thing, wrong priority or wrong understanding. When we change our view of patience from waiting for something to being on the lookout for the timing of a change, input or need we shift from being reactive to being proactive. Reactive in that we were consuming our mind and words with things like, “why aren’t we moving” and “why isn’t this done”, to “when is the right time to insert myself or an idea or concept that would help the individual or team”.
This describes the tension for us, do we risk being overbearing, or do we give the team time and space to work through the delay successfully. There are three considerations I’ve gathered over the years, the first two of which are of primary importance to us in order to better understand our response. I’d also like to follow that up with some tips on more specific considerations depending on your project situation.
There is a cost of waiting. As project managers we are keenly aware that value delivery to our project customers is one of our, if not the, foremost responsibilities we have. Sometimes that value delivery is tied to an immovable date, such as an important regulatory review, or a critical date required for business continuity. In any case there can be a significant cost to the organization, or, even worse, cause business failure or to be paralyzed.
But even in less critical situations all projects benefit from delivering value as soon as possible. This is one of the primary reasons why Agile project delivery methods have taken root, primarily in IT systems delivery but also in other project types as well. The family of practices offered in the delivery methodology allow for products that are available sooner and regularly to the project customer. In these situations, the project customer is willing to take on a more involved role with the reward of value, albeit partial value, sooner than in more traditional project delivery models.
This is especially true when you are placed in a project setting where there is high-value scope in the project objectives mixed with much lesser value scope items. The project could be segmented into separate increments, separate projects, or better yet, prioritized with the structure found in an Agile approach. The only problem with that approach is that everyone who has contributed to the project scope did so for their reasons, and the reasons were based on the value they desire to receive. When those scope items considered high value by the organization, it will likely not align with those personal values from the stakeholders. This, then, becomes an opportunity for the Project Manager to manage expectations and negotiate in order to prevent falling into a “winners and loser” perception.
Another consideration is that new builds or significant extensions of a system, the underlying architecture must be put in place in order to build out the features the user values. From a project controls perspective, there is a key milestone that can be added using a Disciplined Agile concept – this is to Prove Architecture Early for which a goal diagram is dedicated. None of the features will add the necessary value if not able to be supported by an architecture. Patience may be required in order to prove your architecture so that the features can be built at the right time. Focusing on the overall benefits to be achieved once the foundations are laid will help shift the stakeholders from feeling they are having to wait to a clearer understanding of timing.
There is a cost of your team’s understanding.“I wish we would have thought of that!”. How many times have we heard that from our project teams? Something is missed, sometimes high impact, sometimes low impact to the quality of our deliverables, schedules or budgets. In previous articles I’ve stressed the importance of learning by doing, there is a tendency for project teams to get bogged down with various blockers, and risks and we need to keep them moving in order to learn how to adapt to what we are encountering.
This, though, is the other side of the equation. If we push the team too hard, or the team pushes itself for that matter, there is a cost that you may encounter in the form of rework or missed targets for the stakeholders. That cost may be reflected in further delays in the customer gaining the benefit they want to realize or a degraded benefit, increased total cost of ownership and unnecessarily complex support demands. There a handful of primary areas we can watch for to ensure we’re not outrunning our understanding:
- Our understanding of the need. When we use the term “need” we are referring to the concept of requirements. To be more specific, need is anything that is required to ensure the value of the deliverable. There are product needs as well as project needs, feel free to insert “requirements” in place of needs in both. These start with the project objectives and are broken down into deliverable components. This is true regardless of your project methodology, certainly there are several methods for doing this such as use cases, UML, Rational, user stories/product backlog, etc. Regardless, it starts with having a well-informed understanding of the project objectives and scope and being able to clearly articulate what will be delivered based on those scope items. If the team doesn’t show actions that clearly contribute to those items through a lack of understanding, we will find ourselves working on the wrong things.
- Our understanding of the technology. You may have read in previous articles that I’m an avid horse owner and rider. I discussed the idea that when there’s a lot of “new” going on we shouldn’t expect our horses to act predictably. That’s also true with projects, especially when adopting new technologies. The learning curve for the team is higher than we expect. For example, we may have included in the schedule training activities for learning the technology, but invariably there will be a point where questions will arise that go beyond the scope of training. Allowing for reserves in the schedule for not just training, but also the risk associated with the learning curve is always wise.
- Our understanding of the change. Change can sometimes be a delicate matter. What for some can be a minimal change, for others will seem to be impossible to handle. Many times there is no budget for a dedicated resource that has the skills and experience to plan and implement an effective change and adoption plan, so the responsibility falls on the project management – or particularly the Project Manager. Because it’s not a primary focus the tendency is to apply a broad brush, so to speak, on change and adoption plans. The problem with that is you can only go as fast as the slowest adopter. There is no value in trying to push forward because eventually the lack of adoption will come back to take resources from delivering further to later groups and audiences. It requires patience to ensure we have inserted our change at the right time to ensure the highest probability of adoption, that right time requires some preparation of the adopters that answer their questions, reduces their apprehension and builds their confidence in the solution.
- Our understanding of the complexity. I’ve found that we tend to view complexity as a backward looking perspective rather than forward looking. What I mean by that is, we view complexity of our current situation based on how we’ve experienced complexity in past situations. This makes it difficult to evaluate complexity in our current situation and manifests itself in tending to try to over-simplify situations that are quite complex, and over complicate things that are simpler. As project managers we can look for a good understanding of the complexity of our project situation so that we can fully appreciate when we should be able to handler more new things or less. Timing is much more critical in higher complexity situations, so it does require our patience to wait for the right time on our various project demands.
There is a cost of reputation for the project manager. Project managers are a unique group of people, especially those of us who have dedicated ourselves to the profession.We often find ourselves in situations where we must influence without authority. This requires a level of credibility that is higher than those that gain their credibility simply by position in the organizational hierarchy.
When I was much younger, I attempted to slip one past my dad. In other words, I was “loose with the truth” about something I had done along with one of my friends. It didn’t take long for the truth to come out, does it ever? Instead of getting one of the various disciplines from my dad’s assorted kit of those things, I got a question that time. He asked, “do you think the truth is your best option?”. I answered vaguely that it depends if people can take the truth and so on, to which he replied, “truth is not your best option, it is your only option”.
The point was made, and it has served me especially well as a project manager. Not only are we accountable for the truth that we understand, but we are also put in positions to communicate others’ truths as to the project, it’s health and quality and how true we are to our commitments. This is true not only for those to whom we report our progress, but also to our team as well. We can’t afford to lose our credibility to any group of stakeholders, it is that much more important given our lack of positional authority.
We owe it to ourselves, then, to be patient in all we do. In this way we can ensure we are clear in our understanding of the current situation, quality, status, team member’s interactions, adoption of the deliverables, or any other project component. If we view patience from the perspective of timing rather than waiting we can “flip the script” so to speak and keep our focus not on what’s missing or we’re waiting for, but on the right timing to insert a comment, new task, conflict resolution or initiate a change that requires adoption by a user group as appropriate to the situation.
Thanks for joining us, in the coming weeks we’ll have more from this series, the “10 Things I’ve Learned as a Project Manager”.