Reality, or False Scope

I recently finished working for an organization that had an ineffective method for defining project scope.  The issue remained perpetual for my 36 months of employment.  With each successive project the project’s scope would increase.  Discussion about the increase would dominate the communication channels, but their processes for defining that scope would categorically ignore large aspects of the scope required to contribute to efficiently managing the projects.

The symptoms of this that affected me the most were the budget and schedule.  Working in an international environment requires advanced knowledge of specific requirements in order to move the proper equipment and teams across international borders.  Without the proper notification teams were unable to cross country lines on schedule.  Due to the organization’s zero tolerance for failure and single layer thin assets we would often sacrifice other lines of preparation to ask high ranking officials for accelerated approval of our border crossing requests.  

The budgeted funds for the defined scope were also lacking.  While we rushed on the front end to cross international borders, we had to fight the PM teams above us who had closed out the projects on their end without paying all of the obligations incurred by their projects at our level.  This was the same organization that had no communication framework for discussing project risk.  Paragraph 11.2 of the PMBOK states that “Identify Risks is the process of determining which risks may affect the project and documenting their characteristics.”  It’s categorically impossible to identify risks when the process for developing a project scope doesn’t include a discussion about project risk.  It’s also politically difficult to discuss your failure to pay a particular bill months after you reported that the project was closed.  These organizational foibles cost our teams the ability to quickly prepare and reset for successive projects.  In this formula, not only was the current project at risk, but the future projects were as well.

What I learned from this process is that having a clearly defined project scope development process can be an advantage, but it can also be a handicap.  As a leader it’s challenging to be firm while still keeping communication lines open for issues as they arise.  The organization discussed here had an inefficiently long and redundant leadership chain. With each link it became more and more difficult to communicate from the bottom up about potential issues.  Over time these organizational realities lead to a the adoption of a zero tolerance culture.  This is one reason why I’ve been a huge proponent of flattening hierarchies and at minimum flattening communication lines.

When it comes to flattening communication lines many people in my organization love to reference leadership examples that involve video teleconferencing equipment (VTC).  While I agree that this technology can play a very productive role, I don’t believe that this technology is a complete solution.  While this tool does allow large audiences to create a multi sided virtual room, that room does not remove the political implications from communicating critically.  In fact, it could severely increase it.

Truly flattening communications lines requires adoption of not just one solution, but multiple solutions.  The axiom that a leader need be a good communicator is truer now than it ever has been.  Leaders need to be connected to a variety of communications tools.  Some of these tools should enable group conferencing (VTC) and others should enable quick and reasonably secure communications avenues such as WhatsApp.  Rocket.chat and Slack.com adopt measures that work multiple communications necessities within a single platform.

If leaders can expand their ability to communicate then we can properly identify problems with the processes we use to conduct projects.  To change the culture however, it’s going to take charismatic leaders time to request bad news at public meetings and be measured in their response to that news in order to make the necessary changes towards project efficiency.  Sometimes a poorly defined project scope is just a symptom.

 

Reference:

Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK Guide) (PMBOK Guide). Project Management Institute.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s