Easy in theory, difficult in practice

I've worked in the delivery space for thirty years.

Over that time, I've seen delivery approaches rise and fall and wars about ways of working rage on. Frameworks, tooling, nomenclature, roles and rituals have changed, but one thing hasn't. Most executives don't care how you deliver as long as business objectives are met. The question they want answered is not which framework to pick but rather what they need to do to get their business results.

Anything else is just mechanics.

I'm not suggesting that executives shouldn't want to know anything about how those results are produced. Such an "end justifies the means" mindset might encourage a command and control approach from delivery leaders. It is one thing to not know how your car engine works when you take it to a mechanic to be fixed but your car is not part of complex adaptive system the way your business processes and supporting applications are.

Leaders should understand why teams are organized in a certain way, how the members of those teams are feeling, how the decisions they make will affect business outcomes as well as the upstream and downstream implications of those decisions. They should know what technical debt is and how the decisions they make can affect that. They should also understand that they shouldn't create walls between delivery and operations.

They should understand if the delivery targets they've set or the constraints they are imposing on teams are realistic. They need to understand what could go wrong but also how they could prevent those risks from being realized. And they must know how they can best use their power and influence to get their projects to succeed.

But whether you use framework A or B, call a delivery role X or Y, or follow a P or Q life cycle is really not that important to them. If they've come up through the ranks from delivery positions they might have some nostalgic interest in this but beyond that it really doesn't matter to them.

So have your "my Kung Fu is better than your Kung Fu" arguments on social media platforms if that makes you happy. Just don't expect your executive team to pick a side or to cheer from the sidelines.

We'd all like to lead projects from start to finish, but the reality is that often times the project manager who kicked it off won't be the one who turns the lights off at the end. Steve McQueen said "We deal in lead, friend" and a fitting motto for project managers is "We deal in change" and that includes our own role.

As such, it is quite likely that you will occasionally find yourself taking over an active project from a departing project manager. In an ideal world, that project manager will have a generous knowledge transfer period and they will be handing over an accurate, complete and current set of key project information but when I've found myself on the receiving end, I've almost never had that pleasure.

While there might be issues with assuming full ownership for your project's financials, forming a positive relationship quickly with the team and other key stakeholders or just getting a clear understanding of project scope and delivery approach, one of the biggest headaches I've experienced has been taking over someone else's project schedule.

Each practitioner will have stylistic differences as to how they structure, populate and update information within their schedules and it might take you some time to understand their "way of working". This is not what I'm concerned with. Unfortunately, many times there are fundamental flaws in how the schedule was created or maintained which will make it tricky if not impossible to use effectively.

Here are just six of the many telltale signs that you might be taking on a schedule which sucks.

• There's no baseline information. As we teach in our fundamentals course, being a proactive project manager is not just about knowing where you are, it's about knowing where you should be, and understanding the implications of any variances. Without having baseline information for key milestones, you can't determine this.
• Constraint abuse. Some practitioners overuse constraints as a lazy way of getting activities to be scheduled on desired dates rather than using dependencies or calendars to do so. On top of that, if constraints are used but aren't documented, you know why a given activity is constrained which means that you will miss out on opportunities to improve your delivery timing if the real world situation which required the use of the constraint disappears.
• Ridiculous resource allocation. Whether it is people, equipment or materials, if your predecessor didn't take the time to ensure a realistic allocation of resources in line with labor contracts, materials availability, cash flow constraints and so on, then activities will rarely be started or completed as planned.
• Spaghetti dependencies. If predecessor activities are located both above and below a given activity, trying to troubleshoot negative float issues or just understanding the flow of the schedule will be frustrating.
• No calendars. Unless you really expect people to work on holidays and take no vacation, a lack of calendars will be another sign that planned dates might be missed.
• Incomplete activities are scheduled in the past. Unless you are a Time Lord or Lady with the benefit of a TARDIS, once an activity's planned start or finish date has passed, it should be rescheduled to reflect when it is expected to be done.

I provide this list as both a risk identification aid for those project managers who take on someone else's project, but also for those who are creating their own project schedules. If you don't want to be cursed by the project manager who follows you, pay heed!

Self-organization doesn't mean anything goes.

Even in a very small company, there are going to be some restrictions on what a team can do, even if those purely relate to meeting cost constraints requested by those who hold the purse strings. This is one of the reasons why I endorse the Disciplined Agile guideline to "Create semi-autonomous self-organizing teams" as it acknowledges that the degree of autonomy is rarely absolute and will vary widely between contexts even within the same organization.

But assuming the members of a team are ready to self-organize, what needs to be in place to enable them to successfully do so?

The first prerequisite is that there is a shared understanding and buy-in of the project's vision and expected outcomes. If there is misalignment or confusion there, it will be pretty difficult for self-organization to take place. Just observe a group of preschoolers trying to play football and you will quickly realize that self-organization is not the right answer for their first time out playing.

Second, there needs to be a clear understanding of the boundaries. Without this, some team members might play it too safe and abdicate their authority for making a decision while others accidentally cross forbidden lines. And as these boundaries can change project-to-project, it is a good idea for team members to confirm what they can and can't do at the onset of each initiative.

Third, there needs to be encouragement and commitment from leadership to help the team self-organize. What this means is that managers need to create the psychological safety required for team members to feel comfortable making decisions and asking questions about what decisions they are able to make. Ensuring that team members and managers are on the same page about decision making authority is critical and exercises such as delegation poker can be used to safely explore jurisdictional limits. Never underestimate the unwillingness of some team members to make decisions as they might have been negatively conditioned to just do what they are told.

Fourth, there needs to be a safety net for the organization and the team in the event something goes wrong with the decisions the team has made. There also does need to be some validation that the team isn't violating any policies. Checks and balances are required but these should be done in the spirit of lean governance rather than of micromanagement.

Finally, the team needs to have the discipline to document their decisions. The structure or format for this documentation should be context-driven but whatever rules they have come up with for themselves need to be explicit so that there is a clear understanding of how they will be operating, both for themselves as well as for governance authorities.

Self-organization is an admirable goal for teams to aspire to. After all, one of Daniel Pink's three levers for intrinsic motivation is autonomy and you can't get much more of that than deciding how you will do your work. But to realize this goal, we must first fulfill the five factors.

Secondary risks are those which arise based on the implementation of a response to an identified risk. Similar to other risks, secondary risks can fall into known-unknown and unknown-unknown categories. I’ve never liked the term “secondary risk” as it creates the perception that these are not as important as “primary” ones and this is not the case. A more accurate term might be “response-generated risks” or “effect risks”.

Semantics aside, a day ago I learned a cold lesson about secondary risks.

As readers of my recent articles will know, we recently moved into a new house. Let me clarify that the house itself is not new – it is about 35 years old. When we took possession of the house, I did a quick walkaround the exterior and noticed that there were quite a few wasps that were entering and departing a crack in the grout between two bricks near our air conditioner. Having had a painful experience with a wasp last year, I considered the impact of the risk of getting stung by a wasp outside of my house to be quite high although the probability was low so long as I didn’t bother them.

To respond to the risk, I went to the nearby hardware store and got a can of wasp spray. I sprayed it in the crack and then sealed the crack with some masonry repair caulking.

This response created the first secondary risk which was quickly realized. While new visiting wasps were unable to enter the house, the ones which had entered were now trapped inside and over the course of the next couple of days found ways into our basement living space.

By responding to the first risk, I had created my first secondary risk of getting stung by a wasp inside of the house. The impact was still high but the probability had now increased to high given the increased likelihood of accidental interactions while being in the basement.

As I expected there would only be a few wasps that had got trapped in the house, I chose to respond to the new risk in a similar fashion to the first. I sprayed the inside basement area near the entry point liberally and was happy to see that the response appeared to be effective in eliminating the unwanted guests.

Unfortunately, this response to the first secondary risk resulted in the creation of a second one.

When I woke up the next morning and washed my face I noticed the water was lukewarm. I confirmed that hot water was unavailable from a second faucet in the house and proceeded down to the basement to inspect the hot water heater. After reviewing its user guide, I confirmed that it had shut down as a sensor had detected the presence of flammable gases in the vicinity. As you can guess, the water heater was close to the entry point of the wasps.

While my wife was not pleased that she’d have to take a lukewarm shower, thankfully our water heater is a rental unit and so the technician visit to replace the sensor and start up the heater was no charge.

So the next time you choose to respond to a risk without sufficiently analyzing the consequences of that response, you might end up in cold water!

In the first two articles in this series, I covered the context and planning work which has gone into our move. This article is being written three days after we moved into the new home. Nearly all boxes are unpacked and we've even managed to put some of our home decorations up but there's still a lot left to do to achieve our desired outcome.

Given the uncertainties involved in relocating to a new city and the fact that this is our first move in over a decade, more effort had to be spent on risk management than on some of the other knowledge areas. There were multiple milestones leading up to the move and significant delays or cost overruns in achieving any of them would have been serious. Whether it was getting the demand loan funding on time, ensuring utilities were transitioned over in a timely manner or having the movers show up on time, multiple risks had to be managed.

While the move itself tended to involve a number of negative risks, the post-move stages have also introduced some positive ones. For example, certain renovations which we felt would be required weren't. Thankfully, we had a prioritized list of renos so freed up funding could be quickly reallocated! Nearly every threat risk response with the exception of avoidance was utilized. While a formal risk register wasn't produced, we did have a common understanding of the top three risks on any given day and used expected monetary value to plan how much contingency reserves and schedule buffer we needed to address the impacts of any realized risks. For the most part, the risk management process has been effective so far as none of the identified risks were realized. Unfortunately, we did incur the impacts of an unidentified risk related to cancellation of the scheduled payment of our property taxes but thankfully those financial impacts were minor.

Needless to say, procurement management was heavily exercised in this project. Both products and services were procured using a combination of firm fixed price and time and materials contracts. No RFIs, RFPs, RFQs, or IFBs were issued but we contacted multiple vendors where there was likely to be significant variation in price or quality and went with highly rated ones in cases where the service or product being provided was a commodity. The bulk of procurement activities are still remaining as we have shifted into the high priority renos and upgrades stage of our execution phase, but to date no issues have emerged.

Stakeholder management has been one of the least formally performed knowledge areas although thorough identification had to be done of every stakeholder who needed to be aware of our move. Aside from the sellers of our new home and the purchasers of our old home, there were no other opportunities for misalignment in the overall direction of the project. With those two stakeholders, regular engagement and explicit, clear (and sometimes formal) communication was used to ensure we remained on the same page.

So even though the project isn't done, there are some lessons I've learned which might help if we ever have to move again (not if I can help it!). There are also some opportunities which could be exploited by someone with more entrepreneurial spirit than mine. For example, notifying all service providers of a change of address is an extremely time consuming, manual process. Thankfully most can be addressed online, but some require phone calls and if someone was to offer a service to handle it for you, that might be worth funding!

Looking back at my life cycle choice for this project and the tailoring I performed across the PMBOK knowledge areas, I'm comfortable that the planning and execution effort has met the Goldilocks test and has been "just right"!