Easy in theory, difficult in practice

In my last article, I had written about our current personal project of moving from our current home to a new house in a different city. After it was published, I received some feedback (thanks Luis!) that it would be helpful to provide more context about the project itself.

This initiative was the follow up to an initial project which covered the purchase of the new property and the sale of our existing home. As such, a number of constraints were set before this project got underway, including the moving day milestone, the ceiling budget on home renovations, and available floor space to accommodate our furniture and any renovations we were planning.

The scope of the current project includes the following high-level workstreams:

• De-cluttering, packing & unpacking - this included donating, discarding & giving away stuff that we didn't need in our new home, procuring packing materials, packing & labelling activities and the corresponding unpacking and arranging of home contents as well as the disposal of the used packing materials
• "The move" - this included selecting the moving company, negotiating the contract with them, the move itself, and closing the contract
• Account transition - this included cancelling, updating or setting up accounts for utilities, subscriptions and other services
• Financial and Legal - this included selecting the law firm to represent us, providing them with all required documents, securing our bridge loan from the bank and completing the closing process for both properties
• Renos and upgrades - this work stream includes identifying all desired renovations and upgrades, soliciting bids for the work, negotiating and signing contracts, procuring materials, monitoring the execution against those contracts and closing the contracts

A house move is a good example of a project which could never end as renos and upgrades are an ongoing interest. For simplicity we decided to set an arbitrary project completion deadline of a month and a half after the moving date with all subsequent renos and upgrades being handled as operations or follow-on mini projects. This deadline provides sufficient sense of urgency to get the high priority renos and upgrades completed in a timely manner.

The execution phase of the project has been split into four sequential stages:

• Pre-move planning and preparations
• Moving day
• The first two weeks after moving day including high priority renos and upgrades
• The subsequent month covering the lower priority renos and upgrades

As you'd expect, resource management varies based on the resources and work packages involved. For the work being done by my family, planning and tracking have been informal with the primary objective being to ensure that the "right" person is responsible and accountable for each work item. As our family is a long standing team, the Develop Team process is less relevant than the Manage Team one and significant effort has been spent to ensure that team members are engaged, motivated and focused! For the work being done by contractors or for materials and equipment, estimating resource requirements and acquiring resources has been done more formally.

Quality management has focused more on quality control than on quality assurance. The duration of the work being performed by each contractor is short enough that by providing clear requirements upfront, ensuring that there is a common understanding of those requirements including acceptance criteria, and then using those acceptance criteria as the basis for the Validate Scope process is sufficient. For the work done by our family, checklists and peer reviews are the standard tools we've been using to control quality.

While a project communications plan was not produced, with major stakeholders such as the bank, our lawyer, the moving company and key service providers, written, formal communications have been used. There have been frequent instances of the basic communication model failing which has necessitated follow up with recipients to request acknowledgement or feedback. Needless to say, an issue log has been a valuable artifact at managing such concerns! Within our family and with secondary stakeholders, a combination of verbal and written informal communications have been effective.

In the final article in this trilogy I will cover the remaining three PMBOK knowledge areas. By then, we will have moved to our new home, so I will also be able to assess the effectiveness of our planning!

Changing one's house meets the PMBOK® Guide definition of being a temporary unique endeavor producing a product, service or result. And like any project, tailoring needs to be considered when deciding on the life cycle, the roles, governance and practices which will be used to deliver the project.

We are in the midst of moving to a different city and just winging it is not a viable option as the complexity and financial stakes involved means that applying "some" project management discipline is wise.

Choosing our new house was a prerequisite project and one for which an adaptive approach made sense. While we had a general vision of what we wanted, we were unwilling to lock down all requirements at the onset as we were constrained by what was available on the housing market. Cost was our primary constraint, then scope and finally time. Our understanding of what we wanted evolved over the life of the project and we received frequent feedback based on our visits to different properties.

Once our house was purchased, the move project has followed a predictive approach. Full planning up front does not make sense given the high likelihood of changes so a rolling wave approach was chosen.

I have been acting as the project manager, while my wife and I have shared the role of sponsor. Co-sponsorship is rarely a good idea with most projects, but exceptions are made for every rule, and in this case, key stakeholder satisfaction trumped single point of accountability!

Given the scale and scope of the project, most decision-making has been made by the two sponsors with the exception of those which require external review or approval such as securing a bridge loan.

While we did not produce a formal charter, my wife and I did take the time upfront to discuss the who, what, where and why of the project to a sufficient level that there wouldn't be any misunderstandings later on. An integrated project management plan was unnecessary, but once our new house was purchased I created an MS Excel workbook which has been used for planning, tracking and communication purposes. Changes have been frequent and have been reviewed with appropriate stakeholders and approved by both sponsors. Work streams which have been performed by us are managed using a pull-based approach from a very simple work board.

For scope management, a simple work breakdown structure was created to identify the major work streams which were later decomposed down to individual work items. Given that a progressive elaboration approach has been utilized, certain work streams were fully defined early on whereas others have been decomposed over time.

Cost estimation and budgeting has followed a typical top-down/bottom-up approach. For example, an analogous estimate was determined for renovations and upgrades based on our past experience with our previous two houses. However, once scope decomposition of that work stream had progressed to a sufficient level, cost estimates were derived for work packages and those estimates rolled up to an overall amount. Budgeting and tracking has been done within the same MS Excel workbook as is used for scope planning.

Given the limited number of dependencies between work items, a network diagram and Gantt chart would be overkill so schedule planning has been done with a task list containing planned start/finish dates, staffing and progress information. In most cases, activities are short duration and so a 0/100 progress reporting approach has been utilized. With a fixed closing date, certain work streams have been time constrained and hence having activities start as soon as possible has been a good strategy to respond to schedule risk.

In my next article, I will cover the remaining six PMBOK knowledge areas for our home move project!

Two pillars of adaptive approaches are inspection and adaptation.

These can be applied to the product, service or results being produced by the team as well as the way in which those are produced. For the former the use of Minimum Viable Products, Spikes, Minimum Marketable Features and Minimum Business Increments are used to reduce the impacts of building the wrong thing.

But what about changes to the team's way of working (WoW)?

Whether a team uses a scheduled cadence for reviewing their WoW such as the use of retrospectives in Scrum, or they use a just-in-time approach they will come up with improvement ideas.

Some of those ideas will be all or nothing.

For example, if the team has frequently encountered delays with getting support from an external subject matter expert for completing some work items, they could lobby their sponsor or project manager to have someone possessing the same skills to be assigned to the team.

But many times, there might be more than one way to implement the improvement.

Let's say a software development team recognizes that they need to improve their code quality and to do this there are many options available. Coding standards, coding reviews, non-solo coding, test-first development, and automated code quality tools are just a few choices. The team might eliminate some of these based on their context. For example, they might not have sufficient budget left to purchase a new tool. But once they've eliminated these, they still have to make a decision about how they will implement one or more of the remaining options.

This is where a Minimum Viable Improvement (MVI) can be utilized. Similar to an MVP which is used to maximize validated learning about a product with the least investment, an MVI can be used to validate the team's belief that a given improvement idea will work.

In our example, let's assume the team is interested in trying a non-solo development approach.

They could fully commit to it by having the full team adopt pair or mob programming, but implementing one of these practices wholesale might be too disruptive and if it doesn't work, the impacts would be significant. On the other hand, an MVI might be to find two volunteers within the team who are willing to try pair programming for their upcoming work items.

To be a valid experiment, certain variables would need to be controlled. The volunteers should be representative of the average capability within the team (i.e. you wouldn't want to run the experiment with either the best or worst quality developers) and the work items they pulled should be similar to work which has been completed in the past so that comparisons using quality metrics are possible.

Once the work items have been completed, the team can regroup to review the results and decide whether to proceed with a larger experiment, pivot or tweak the pairing approach, fully productize the practice by making it part of their WoW, or punt it if they recognize it won't work for them.

Taking an MVI approach will minimize the cost of learning and change to just the volunteers directly involved and the risk of work being completed at a lower quality level is restricted to just the work items they pulled.

So the next time your team comes up with an improvement idea, propose that they frame it as a hypothesis and design an MVI to prove or disprove that hypothesis.

The latest version of the Scrum Guide states "The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management."

Depending on how one interprets that second quote, taking minutes from the standup might seem to be an acceptable technique. Certainly if someone outside of the team has imposed this requirement that would be a "bad" thing, but what if the team has decided to do so for themselves?

Let's take a look at some reasons why someone might want to have minutes produced from daily standups.

1. We discuss so much that we need to ensure that none of the actions or decisions get lost. This smells fishy as how much could possibly be covered in under fifteen minutes which would be forgotten over the course of a single day? This might be caused by a team taking longer than the recommended duration or going too far down a rabbit hole regarding a single topic which might have been better taken offline with a smaller group. Now if one team member is concerned that they might forget something of importance, they could certainly take some personal notes, but producing minutes is overkill.
2. Some of our team members aren't able to attend the daily standups. If this is a chronic situation, then the team might want to discuss the timing of the standup as well as confirming that it is deemed to be of value to the team as a whole. But if once in a while someone is unable to attend, then a better approach would be for that person to follow up with one of their fellow team members afterwards to get up to speed.
3. Someone outside of the team wants to understand what's going on. Great! The team should welcome an outsider who is genuinely interested in the team's work and should invite them to participate as an observer at the event, or, if they are unable to do so, point them to the key information radiators and artifacts (e.g. burndown charts, work board) used to support the discussion at the daily standups.
4. We need to hold the team accountable for their work. And you feel that producing minutes from the event is going to create accountability if there is no follow through on what was discussed at the daily standup? Sounds like some serious coaching is needed with the stakeholders who are feeling this way.
5. We need something to confirm what needs to be updated in our work board after the standup is done. Really? If the team truly embraces the pillar of transparency, then their work board should always reflect the current state of the work and their work flow and shouldn't need to be retroactively brought up-to-date.

I'm not against documenting outcomes from the standup where it will be of value to the team. For example, if a particular work item is blocked and the team feels there is value in updating the work item details with their plan of attack, more power to them. But these should be informal, minimally sufficient annotations that could be made by someone during the standup itself.

Anything beyond this is a form of waste at best and an invitation for micro-management from stakeholders outside of the team at worst.

I was a member of Review Team 1 for content within the Seventh Edition of the PMBOK® Guide and had the opportunity to provide feedback on key chapters of both the Standard and the Guide sections of the document in late 2019. The PMBOK® Guide's content has significantly evolved since then and having had a chance to read through a digital copy of the final published document this week, I wanted to share my thoughts on it.

There's no question, this edition has generated more controversy and polarization of opinions than any which preceded it. Scores of articles and webinars have been published over the last two years from proponents and detractors of the new principles-based approach.

No one can say that project managers aren't passionate about their profession!

While a few of the concerns raised came from pure resistance to change, most were objectively focused on issues with either the content within the document or the approach which was taken to solicit feedback from the membership. While there was a public opportunity to provide feedback on the Standard section of the document, only the review team members had the chance to do so for the Guide section. It should be noted that PMI's qualification process for inclusion in the teams did result in diversity of thought in the feedback provided.

But enough about how we got here - how do I feel about the end result?

I've read every edition of the Guide from the Second onwards. As such, there is a natural inclination to compare. But given that the Guide has been fully rewritten with a different philosophy than earlier editions, this is not an "apples to apples" comparison. So while reading it I attempted to adopt the persona of someone who had never picked up a copy of the Guide.

Here are five observations which came to mind after reading the document.

1. The overall topic of tailoring is an integral part of the document. I liked the tailoring lifecycle as well as the natural way in which tailoring choices were covered throughout the Guide. It would have been better had the team referenced and integrated Disciplined Agile concepts within the Guide as tailoring has been part of that toolkit's DNA from day one.
2. While the Models, Methods and Artifacts section is not comprehensive, I do like the focus on the vital few as well as the balance in coverage between predictive, adaptive and hybrid approaches. What could have been improved was the linkage to PMIstandards+™. The Guide does state that the process-centric details of previous editions are available on that online platform, but it would have been better to have had a tight integration between the two such as having unique codes listed on pages of the Guide which could have been used to locate related content in PMIstandards+™.
3. The acknowledgement that there is a linkage between project and product management and that a product-centric approach might have benefits over a project-centric one was refreshing.
4. I appreciated the content on motivational theories as well as the appendices which focused on the critical role of the project sponsor and the benefits which a PMO can provide. However, the opportunity to have added a principle which highlighted the critical role a project manager can play in building psychological safety and the importance in doing so was missed.
5. The principles are valuable and well stated. I liked the mention of the interactions between specific principles, performance domains and between individual performance domains. I did find the Checking Results section of each performance domain to be superficial and hope that it is enhanced in future editions.

Like it or hate it, the Seventh Edition of the PMBOK® Guide is a valuable reference. I found it to be more readable than previous editions, but as with all products, there is always room for improvement.