- Setting up Auditing & Logging of Files/Objects Using Native Windows File Server Tools - 16th October 2020
- Designing Key Performance Indicators (KPI) - 15th July 2020
- DDOS Attacks and Website Hacking - 6th July 2020
Programme and Product Managers make various decisions, from deciding on the work schedule (Programme Managers) to the detailed functionality of the products (Product Managers). As with any decision, there is always a risk that that decision has not been made effectively or obtained necessary agreement as the correct one with stakeholders. In this blog post, I discuss how I make decisions as Programme Manager or Product Manager, and broadly, the framework I use to make those decisions. The ideas expressed below are based on my experiences and the books Execution: The Discipline of Getting things Done and One Minute Manager Meets the Monkey
I’d like to first of all call out that I am, and have always been, a big believer in what I call Consensus Driven Project / Product Management. Meaning, unlike Homer Simpson, trying to avoid making decisions unilaterally. Instead, I believe it is always better to reach as broad a consensus as possible (unanimous agreement is, alas, not always possible) with the stakeholders on the options available and then work towards further building a consensus around one of those options, having clearly called out which option I would favour and why.
My general approach to this aim is to have as many people as possible participate in the decision making process. This does have the tendency of sometimes slowing down the decision making process, or making arriving to a consensus more tricky. However, the benefits of more participants in the form of better ideas, more thoughtful risk management (i.e. risk taking) and raising of alternative option outweigh the negatives. In my view, spending more time to make a better thought out decision, usually outweighs the benefits in the long-term of making quicker decisions – no matter how attractive at the time speedy decision making might seem.
In order to achieve this, I find what works well is using the Daily Standup to make everyone aware that we have to make a decision on something and for which I will be setting up a meeting to have a decision making discussion. I then state who I will be inviting to in that meeting as I feel their participation is needed, and then asking anyone else who feels they need to be in that meeting to let me know so that I can forward the invite to them. This avoids the Programme or Product manager inadvertently missing out on not seeing things from an important different perspective because someone was not part of the decision-making meeting. It’s also worth keeping in mind that sometimes, if the decision is a less major one, or broadly there’s a consensus already, the decision can just be made quickly within the Standup through a short discussion.
I also try and include external stakeholders and programme business sponsors to some of the important decision making meetings, even if it’s an optional invite for them for a discussion where they can observe and don’t need to participate. This usually proves beneficial in the long run as It helps give people who wouldn’t necessarily have a view into the project a look at the challenges being faced and the hard work being done, and generally helps raises the sponsor’s confidence in the team, not to mention also builds a better relationship.
Unless the decision is pressing and there is time pressure where ad-hoc, dedicated sessions must be setup for decision making discussions to take place, I believe the Sprint Retrospective, or a weekly programme / portfolio status review / update meeting are optimal forums to have these decision making discussions.
Furthermore, getting into a habit of having a regularly updated register/log of risks, issues, and change requests, prepared by the Programme Manager and shared with the participants the day before a status review meeting, sets a good rhythm for the life of the programme. Having such a review and discussion regularly helps in running an efficient programme by having well-organized meetings with focused decision making.
I have participated in meetings where it’s unclear who has the final say on the changes – is it the programme manager, the participants, or the business / executive sponsor? And if it’s unclear how a decision is made and whose input is required, it’s actually unclear if a decision has really been made and if it should be actioned. Some people might start implementing the decision, while others will not follow it through without further actions or clarifications.
It is for this reason why the first aspect of the framework is stating the decision clearly so that everyone has clarity of the situation
The first, perhaps most important, part of the framework is clearly stating the situation at hand. This involves clearly stating:
- What is the situation that needs addressing
- Why does this decision need to be made, i.e. what will happen if a decision is not made
- Who needs to make this decision
- Who will be impacted by the decision made
- Who will need to carry out activities based on the decision reached and what those activities will be
- Any costs associated with the decision made
- The negative and positives of all of the options available.
For major, programme or business impacting decisions, it is always best to state the above in writing, and have it circulated with all the participants preferably 24 hours prior to the meeting so that they have had a chance to study it and gather their thoughts for the meeting.
“We have the smartest people in the world. The question remains, how to you get them rowing in the same direction?”Bob Swan, CEO, Intel
A consistent approach to decision making needs to be applied to have people move together in the same direction. Needless to say, this is not easy. This approach needs to give people clarity on why a decision is being made, how that decision will be reached and whose input is required. There are, generally speaking, five types of decisions we can make in our professional (and personal lives). It’s these five types that form the five different approaches for making decisions in the framework.
This means that everyone required to make the decisions supports the proposed solution or idea. A unanimous decision creates strong buy-in and shared ownership, and it leverages the collective creativity and knowledge of the people present as everybody involved will have contributed. It is particularly helpful when a strategic decision is needed, such as, if a release should be forked to meet a need of a new client.
The disadvantage of this approach is that, as it requires a mutual understanding and evaluation of competing ideas, it usually takes more time, multiple meetings – both collectively with many departments and one-to-one with individual team members – to reach unanimity.
We also need to be mindful that our efforts to build unanimity does not descend into design-by-committee where an agreement is brokered into a weak compromise. This is unlikely to result in a sustainable agreement, rarely turns out a successful product and usually results in deprecated releases and wasted build effort until a successful product is finally agreed upon.
Similarly, programme and product managers need to be very, very, mindful that they don’t become a factor that prejudices the decision-making process by unduly influencing it or allowing an individual to dominate and high-jack it. I find that this is best achieved by the Product/Programme Manager taking note of any ideas that may have not fully played out in the discussions (perhaps because of the natural ebb and flow of a conversation) and vocalising it later on in the meeting to restart the discussion on that point. It is for this reason why I prefer having a meeting facilitator present for large or critical meetings who can assist in setting up and administering the meeting, guiding the decision-making process, and generally supporting the Product Manager or Programme Manager, such as a Scrum Master, or Project Management Officer (PMO).
This is when a decision is made where nobody disapproves of the decision made. In my experience, a unanimous decision is not always possible and a decision with an absence of objections is usually the best that can be achieved. Applying this approach is beneficial when you don’t have the time to decide by unanimity or a “good-enough solution” is sufficient.
Once the proposal has been discussed and a shared understanding has been established, participants clearly state if they object or consent to the proposal. If there are any objections, they are investigated in the meeting. The proposal can be amended there and then if possible, or reworked offline for another subsequent decision making meeting where a consensus based on there no longer being any meaningful objections can be achieved.
The drawback of this approach is that it does not give you the same degree of buy-in as unanimity because not objecting to a proposal does not mean that people are happy to support it. However, this can be dealt with by clearly stating the activities that need to occur to implement this decision and naming the people that are responsible for carrying out those activities.
As a Programme / Product Manager, the thing to be careful of here is not to hasten the decision-making process by inadvertently not considering all meaningful objections. For consent to work, everyone involved in the decision-making process either must be OK with the proposal, or at the very minimum due to time pressure, accept the rationale behind the decision taken.
Here, you consult with SMEs over an idea or solution, but, due to an unavoidable constraint, such as time-pressure like a calendar bound release (for e.g. in time for a seasonal sale), you ultimately decide.
The benefit of this approach is that it gives you the benefit of expert knowledge, but speeds up the process by limiting the actual decision to the Programme or Product Manager. The major disadvantage to this approach is that there is a higher chance of making the incorrect decision as no consensus may actually have been achieved, or a decision against the advice of the SMEs is taken.
A variation to this approach is to delegate the decision to only the SMEs. By all means, the Programme / Product Manager continues to participate in the decision process, but mainly as a facilitator. For example, as the person in charge of the product or programme, you might delegate decisions about how to write, refine and prioritise certain user stories to the requirements management or business analysis team as they might have the most regular contact with the end users and thus knowledge about the feature demands.
This form of delegation helps ensure that the best qualified people are involved in the decisions, and it ensures the Programme / Product Manager does not become a decision making bottleneck. It also sends a positive signal to the appointed decision makers: It shows that you trust them and value their expertise.
Another benefit is that as the Programme / Product Manager is still part of the decision making process, even as a facilitator, there is still ample opportunity for the Programme / Product Manager to ask any questions and get involved further if needed.
My least preferred approach, but sometimes the inevitable and unavoidable one.
As the person in charge of the programme or product, you don’t have to involve others in all of the decisions. Just as delegating responsibilities effectively is good management and necessary for sustainable success, there are lots of occasions where decisions have to be made on your own. For example, should a problem be escalated to executive management or does a troublesome feature need to be removed to meet a critical release date?
Be aware, though, that this approach is usually successful if used rarely, and judiciously, if you have the right knowledge to make the decision, can justify those decisions at a later date when the (possibly negative) result of that decision is known and you don’t need buy-in to the decision from others.
Take the example from above where you decide to remove a feature from a release that would not be ready in time for the seasonal sales otherwise. If you are confident that the stakeholders will agree with your decision, and that the feature does not impact critical functionality, and a decision has to be made immediately because advertising deadlines, perhaps, have approached, and the customer facing sales team cannot provide input on a feature that isn’t even available for review in a pilot yet, then you can reasonably be assured that you are the only person who can make this decision.
But, in this example, if sales will be impacted, or if time is available for discussions to take place with the Sales and Marketing department, then it is far better to consult with them to reach either a unanimous agreement, or an agreement with the absence of objections with dependent teams given extra time to prepare for the impact.