Friday, June 24, 2016

Program / Project Management Styles

Effectively managing programs or large projects is about choosing the right people, tools and style depending on the situation, or the environment. I have seen a lot written and taught about managing people in a project team, and about the tools and methodologies of managing the deliverable. But, I haven't come across a whole lot of practical, useful literature about understanding and aligning management styles to project situations. So, I put together a few points from my experience in the 2x2 matrix below:

There are several factors that contribute to a project or program's situation, but two big impact ones are the scope and the stakeholders (here is an excellent article on stakeholder management).

Please note the following pertaining to this particular article:

  1. The words scope and requirements are sometimes used interchangeably in this article 
  2. Stakeholders include all major decision makers, including clients and end-users. However, project execution team (including Project/Program Managers) are not included in its definition for the purpose of this article 
  3. While we speak about these quadrants, please note that in reality it is a continuum on both the axes. So, you will not only have to assess which quadrant your situation belongs to but also to what extent it falls in that quadrant. And tweak your style accordingly 
  4. Please note that Passive Stakeholders or Fuzzy scope are not necessarily evil, though they make the project a lot more challenging. All I am saying is that the Project Manager must pay heed to these parameters and adopt accordingly. 

Alright. Coming back to our topic, when you consider a situation to be a function of scope and stakeholders, four distinct management styles emerge:

1. Contractual 
This style come into play when you have very well defined scope and requirements, but stakeholders are not actively involved. Almost like a client who gave you a fat requirements document and said "here, take this, do as requested, and don't bother me much". A few salient points of this quadrant:

  • Usually, Schedule / Cost Management takes priority
  • Important to agree upon and enforce a well defined communication strategy 
  • Need to develop subject matter expertise in team 
  • Conforming (ask-do-adhere) execution strategy: Not only is it important to adhere to the defined requirements of the project, any innovation, modification needs to be explicitly signed off by the stakeholders before implementation 
  • Difficult to build relationships in this situation 
  • Strive to move to the Clockwork quadrant, if possible

2. Cautionary 
When you have a situation where the scope is not clear enough, and the stakeholders are not present enough, then you have a very risky project at hand. So the following salient points define this particular quadrant: 
  • Project Risk Management takes priority
  • Over communicate. Every minor detail needs to be communicated in whatever channels are being used (email/ IM/ review meetings etc.)  
  • Develop subject matter expertise in team. This is important because they can help guide and give direction to the team instead of waiting for the stakeholders  
  • Adopt an Exploring rather than Conforming execution strategy. An exploring strategy means that the team can explore options, and propose solutions instead of waiting for someone else to define them. In the absence of clear definitions and adequate involvement from the stakeholders, proactively taking control of the situation is important so as not to derail the entire project in the long run 
  • Politically dangerous situation: Whenever there are blurred lines of responsibility, and unclear decisions, the situation is rife for finger pointing, CYA (Cover Your Assets) behaviour and dirty politics 
  • If you are in charge of the project as a Program Manager or Product Owner, strive to move to Contractual or Nimble quadrants. This can be done by helping to define scope well enough, or by motivating the stakeholders to get more involved in the project. 
3. Nimble 
Imagine that you are working with a client to build them a bespoke business platform. They are very well invested in the project in terms of their time and involvement, but the requirements are not all defined because they themselves are discovering new things as the project progresses. In this situation, it is important that the project team understands the situation and adopts a nimble approach, instead of labeling the clients as "indecisive" or "ignorant" and forcing them to write requirements that they don't themselves understand yet. 
  • Use Iterative Methodologies, like Agile  
  • Scope / Requirements Management takes priority. This might be achieved, for example, by agreeing on the larger vision and nailing down detailed requirements only in each of the iterative cycles 
  • Agree upon success criteria and operating strategy. This is especially important when the scope is unclear and you can't have a 1 to 1 map of requirements and deliveries 
  • Record decisions and action plans. As the project team keeps reacting to changes, it is very easy to lose track of decisions and inflection points. Hence, make sure accurate change records and meeting minutes are maintained 
  • Show thought leadership, if possible, to gain trust. In a changing situation, clients appreciate partners who show knowledge, credibility and sense of ownership. 
  • Project team can adopt Exploring at macro, and Conforming at micro level execution strategy. So, the team would work with stakeholders in exploring options and requirements and then deliver as per the agreed scope 
4. Clockwork
A very well defined scope and an actively involved client- seems like a dream situation. But, it can also be perceived as an unnecessary micro-management by the project team. It is important to define roles and governance framework even in a project that can be executed like a clockwork. 
  • Quality Management takes priority, because a client who has invested in detailed requirements and attending to the project team as and when necessary has every right to expect nothing less than what was agreed upon 
  • Avoid surprises, as each unexpected event nibbles away at the bridge of trust between the project team and the stakeholders  
  • Challenge assumptions and seek clarifications 
  • Team can follow a largely Conforming execution strategy, as scope is well defined and stakeholders are available to address concerns or challenges in time 
  • Try to over deliver, innovate and build credibility, but not deviating from the agreed scope  
  • Keep stakeholders “warm”, or risk sliding into Contractual quadrant. I have seen a few projects that started with stakeholders being actively involved but then they slowly reduced their presence as the project was progressing smoothly. To avoid this, make sure you have adequate formal and informal touch points with them and you maintain the communication as well as the relationships 
I must emphasize once again that the above axes and quadrants are not crisp but rather a continuum. So, some projects are better defined than others while some times that stakeholders are more active than at other times. It is important for a PM to understand the styles required in each situation and act accordingly. And it is also important for a PM to watchout for times when a project can shift quadrants. For instance, I once worked in a team developing a mass market software product that was predominantly a Clockwork project. But then, we were told that a competitor had just launched a similar product so the offering had to be re-jigged to remain attractive. It required us to move to Nimble phase and make the delivery in a phased manner, over a slightly longer period of time.