Project Management

The E-Mail Iron Triangle

In traditional project management the axes of success are usually denoted as cost, scope, and schedule.  This is often known as the 'iron triangle' as it was once believed that if one thought about it long enough (and estimated accordingly), each of these 3 axes could be fixed.  These days most sane projects are executed with an understanding that, at most, 2 axes can be fixed. 

The farther that communication is removed from face-to-face interaction the less effective that communication is.  For numerous reasons, face-to-face is better than telephone; telephone is better than texting; texting is better than email.  Co-locate where possible!  Yet, due to geographical distribution of companies, their teams, and their customers the need for this type of communication is unavoidable.  The cost of that decrease in effectiveness is rarely taken into account at the project level.  Let's consider the concept of the 'iron triangle' in the context of the use and proliferation of email communication on projects:

Scope

As projects progress, people are involved in communicating via email at different frequencies and urgencies and for different purposes.  These email volumes (some portion of the scope of our work) are always underestimated and perhaps most puzzlingly, are not considered by some to be actual 'work'; they're considered something separate.  In the Creative Economy of knowledge work,  email is unfortunately a huge part of the work.  Solving problems requires collaboration and the exchange of ideas and if we choose to have these conversations asyncronously (for whatever reason) through email then we must accept that we are working at an often reduced velocity.  In order to maintain a level of thoughtfulness in engaging in these asyncronous conversations, we each have a volume threshold beyond which the quality and timeliness of our responses will suffer.

Cost

The cost of 'keeping up' with the ever increasing volumes of email usually results in:

  • a decline in the quality / timeliness of the work,
  • an increase in the stress of the people involved,
  • the realization that the work needs to be subdivided and additional people involved, or
  • the realization that less people need to be involved in the work

As email volumes increase unhindered, the cost can only increase.

Schedule

As email volume increases, the ability to respond meaningfully in a timely manner decreases.  This leads to people trying to multi-task by responding to emails amidst other communication mechanisms like meetings/ teleconferences. This in turn reduces the quality of at least one and likely all of those communication mechanisms.  Often an illusion of responding in a timely manner only creates churn due to incomplete answers or incompletely thought through responses.  People need time to communicate effectively.

 

So if scope increases beyond a threshold, cost and/or schedule will increase.  Most people have exceeded their threshold. That threshold can only be avoided by taking a hard loo at working communication agreements, communication conventions, and individual systems tailored to each person's working style.  Until these true costs are effectively considered on projects, the E-Mail Iron Triangle will remain fixed along all three axes and people, teams and organizations will continue to suffer the consequences.

How can you tell if your threshold for email has been exceeded?  Some symptoms are:

  • feeling the need to respond to email while doing something else
  • having to respond to an email multiple times because you didn't give it the time it deserved initially
  • hearing yourself say on any given day "I haven't caught up to my emails from yesterday yet"
  • feeling like you may have missed an email, but you're not sure because you have so many (unread or read) cluttering your inbox.

If you've experienced these symptoms,  you, your team, and your organization probably need to examine which two axes of the email iron triangle you want to anchor and which you're prepared to let float.

What's in a Title?

Much is made about the title of 'Project Manager' and the need (or not) for that position in agile software projects.  I've always felt that the role of Project Manager is different than the role of a Scrum Master even though the roles are often attempted to be filled by the same person.  While there may be some overlap in the roles, the Scrum Master is generally focused internally toward the team and the Project Manager is often focused on activities that affect the team but are external to the team.  A Scrum Master would be focused on guiding the team through the Scrum framework, helping the team improve their effectiveness, and removing impediments for the team.  A Project Manager is often tasked with ensuring that regardless of what is transpiring within the team, the team is aligned with current corporate protocols and constraints.  Ideally, of course, the entire organization is using an agile mindset and the role of Project Manager is subsumed by that of Scrum Master. In reality, at least as a transitional move, the two roles are still required during the early stages of an agile transformation.

The role of Product Owner and/or Manager on a sofware project should have the responsibility for making all the business decisions related to scope, budget and schedule because they are supposed to have the most understanding of the value created and the business priorities for the marketplace.  Other members of the team (and indeed of the organization) may have different opinions but it is the role of the Product Management discipline to make product business decisions.

In Oil and Gas Facilities construction, the Project Manager is the arbiter of ALL of those same business decisions.  It is from the roots of construction/manufacturing that software development took its first organizational steps and so it is not surprising that the title of Project Manager has been confused.

An Agile Mindset in House Construction

New Construction

One of the arguments purporting to negate the logic of agile principles comes from the analogy of building a house.  It is said that no one in their right mind would build a house incrementally - finishing a bathroom, then finishing a kitchen, then finsihing a bedroom etc.   There's no value in the house until the entire house is finished, which is why they are constructed based on task sequence effeciency: all structural followed by all plumbing followed by all electrical etc.

After a conversation with a colleague, Brent Walker, it became clear to me that building NEW software is not analagous to building a house, it's analogous to building a housing subdivision.  The subdivision is a system of houses just as software is a system of functionality.

Developers buy land and install basic infrastructure for the subidivision: roadworks, electrical, and waterworks.  They then build and market houses one at a time to accrue value on their investment, tieing in the basic infrastructure to each house.  They do NOT set out to finish all houses in the subdivision at once when the last finishing task (painting for instance) is completed on all houses.  They serially accrue value one finished house at a time.

In continuing the anaology, the finished software application is the housing subdivision and the incremental valuable story is the house.  Agile principles stress the importance of accruing incremental value by finishing stories one (or a few) at a time as early as possible rather than having them all partially finished at any given time (thus delaying value accrual).  The bedroom or kitchen in any one of those houses is more akin to a task necessary to meet the acceptance criteria of the story.

Renovations

Many software development projects are similar to house renovations; you want to add value while still accessing the existing value.

In June of 2013 a major (>100 year) flood in our town caused us to consider renovating our basement.  We had to remove the flooring and strip the walls to the studs.  In so doing, we also decided to reconfigure the space from a project room and large common room to two bedrooms and a smaller common room.  Each area to be renovated required some framing, some electrical (lighting), sound insulation in the ceiling, drywalling, mud/taping, painting and cement floor polishing in order to be considered done.

After completing the electrical in all rooms and hanging the drywall in the first bedroom, the question arose as to whether effort should be spent finishing hanging drywall in ALL areas (both bedrooms and common room) before moving on to mud/taping, painting and floor-finishing or whether each room should be taken to completion in series.  Mudding/taping all at once, for instance, would minimize the incidents of mess and dust inherent with the drywalling process.  However, with only 6 weeks until Christmas, the entire basement could not be finished.  It was decided it was more important to have both bedrooms ‘usable’ (drywall hung and providing at least visual barriers) before Christmas to allow for the bedrooms to accomodate likely holiday visitors; the Minimum Marketable Feature given the time constraint.  The state of the common room in-between was less important and therefore effort was not spent hanging drywall in it.  After Christmas, it would be more important to finish the bedrooms prior to the common room even though that would likely require more more instances of drywall dust/mess.

Performing one task across all rooms has the apparent value of being more efficient as there would be less context switching and less instances of disruption but taking that route also DELAYS the principle value of each of the bedrooms; having private spaces ready for use by holiday visitors.

Project grammar

I sometimes wonder if the field of Project Management spends too much time emphasizing management of the noun vs management of the verb.

PROject (n)
A temporary group endeavour undertaken to create a unique product, service or result.

proJECT (v)
To thrust forward.
To estimate or predict based on present data or trends.
To direct one's voice so as to be heard clearly at a distance.
To cause an image to appear on a surface.

Isn't project management really about managing the actions/decisions necessary to achieve a desired outcome?  Focusing on projections of the desired outcome, based on present data or trends, is how we truly manage risk on a project; the risk of shipping the wrong product, the risk of shipping a low quality product, and the risk of shipping late or not at all.  The first key to mitigating these risks, of course, is to ensure that the present data and trends used to make the projections are both valid and valuable.  The second key is to update the present data regularly, accordingly update the projections, and then make decisions.  These concepts describe two of the primary elements of iterative/incremental development.  Successful proJECT management is much more akin to causing an image to appear or hearing clearly at a distance than it is to simply endeavouring to achieve a result.

The Bus

In Jim Collins' "Good to Great" he touched on great leaders taking steps to ensure that the wrong people were off the bus and that the right people were in the right seats on the bus.

In his follow up, "How the Mighty Fall", Collins explores how once-great companies disappear into oblivion and how some manage to turn their decline around.  Once again, the first step that leaders take in trying to resurrect a company involves the concept of 'the bus'.  Here's how you know whether the right people are on the bus:

  • The right people fit with the company's core values.

    • You don't figure out how to get people to share your values ... you HIRE them based on your shared values.



  • The right people don't need to be tightly managed.

    • The right people are self-motivated and self-disciplined.



  • The right people understand that they don't have 'jobs'; they have responsibilities

    • These people can articulate that "I am ultimately responsible for ...".



  • The right people fulfill their commitments.

    • They take commitments seriously and thus are careful not to over-commit.



  • The right people are passionate about the company and their work.

    • Nothing great happens without passion.



  • The right people display 'window' and 'mirror' maturity

    • When things go well they point out the window to others, when thinks don't go well they point to the mirror.




My experience has shown me that having the right people on the bus is the most critical part of creating and maintaining a successful software development organization.  Keeping the wrong people on the bus has enormous risks associated with and it is always more cost effective to remove people from the bus as soon as possible rather than keep them around for perceived short term gains.