Tailoring project management for a home move (part 2)

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!

(If you liked this article, why not pick up my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores)

Go slow (to go fast later)

The January 2020 issue of PM Network provide a case study for one of the 2019 PMI Project of the Year finalists, the Société de transport de Montréal’s (STM) eight-year project to modernize the underground Montréal rail system. I have a soft spot in my heart for this system, having spent most of my formative years in Montréal and having been a frequent user of its services while commuting to university and my first job. I always found it to be a clean, safe, efficient and reliable method of getting around the city. As such, it was a bit of a surprise for me to read about the operating challenges faced by the STM in recent years and the anticipated growth projections, both of which were the impetus for this ambitious project.

While this would be considered a small mega-project (CA$2.1 billion), it is still a testament to the team that they delivered it under budget and on schedule utilizing only one percent of their overall contingency budget. The post-project outcomes are also in line with expected benefits.

What impressed me about the case study was the number of practices which were used by the team which we would normally associate with projects following an agile or adaptive life cycle. This includes close collaboration and short feedback loops with customers, building a “whole” team representing all disciplines, performing operator training in parallel with build activities to streamline transition, and encouraging learning from failures rather than hunting for scapegoats.

However, what really resonated with me was the team’s commitment to shifting quality left.

During the preliminary qualification phase for the new trains, problems were identified during integrated testing which hadn’t been identified in the manufacturer’s unit testing of the individual components. Rather than blaming the contractors, STM owned the issue and worked closely with them to fully resolve the issues. While this caused a two year delay to the qualification phase, over the remaining life of the project it resulted in minimal change requests and contributed to acceptance of the trains upon final delivery with no costly late stage rework required.

Complex projects often experience design or other solution-related issues early in their life. While no one likes reporting negative schedule variance, especially at an early stage, if these issues do not get properly resolved, or worse, are ignored to protect schedule performance (and to save executive embarrassment), the cost and schedule impacts will often be much worse later on.

Courage is one of the values of the Scrum framework, but it applies to all delivery approaches. As project managers, we need to have the courage to convince our executives that it is better to slow down now so that we will be able to speed up later.

A stitch in time saves nine!

 

 

 

 

A camel is a horse designed by a committee

The old saying about committees came to mind when I was considering the default approach companies often use to achieving a control objective. Bringing together diverse perspectives can help to reduce bias, but in many cases a simpler approach might result in a better outcome.

Let’s focus on the specific example of a solution architecture review.

It is rare that there is accountability for each member of a committee if their decisions were poor as they have no skin in the game. The power imbalance between the committee and the creator of the architecture proposal being reviewed might also encourage nitpicking over format or style rather than substance.

There is also an increased likelihood of incurring delay and other forms of waste. Committees meet at scheduled intervals which might not align well with the needs of a specific team. The committee might also be faced with a “feast or famine” challenge where they are overwhelmed with submissions at some meetings with the result that certain teams don’t get their proposals reviewed. Beyond the proposal review itself, there is usually a need to go through some type of formal intake process and to provide other documentation for committee-specific needs. The overhead costs of running the committee are likely to be charged across all teams.  And don’t get me started with the increased costs of re-work or repeat reviews beyond the initial presentation…

So let’s consider a simpler alternative as the default approach with a committee used only an exception basis for the most complex situations.

Why not require all architects to spend a fixed percentage of their capacity on conducting structured peer reviews of each other’s architectural proposals? Each architect is expected to have a clear understanding of enterprise standards and good architectural practices, so control objectives should still be met.

This addresses both of the previous disadvantages:

• Greater skin in the game. The architect who reviewed the proposal will be sharing accountability for the outcomes with its creator. On top of that, should the reviewer not be fair in the review process, this behavior will be rewarded in the future when it is his or her turn to be reviewed.
• Reduced delay and waste as it is much easier for two people to meet than a committee and the level of process or bureaucracy around the review can be minimized.

It might also result in a better architecture as we may be more open to incorporating feedback from one of our peers than a group of seniors.

Ensuring that there is a fair balance of review work across all architects might be achieved through some sort of random allocation system that prioritizes reviewers based on their last review date.

Delivering in a leaner manner should not require sacrificing the control objectives which will keep us safe, it will just require re-thinking how we approach governance.