some indie thoughts on management, leadership, strategy and execution of software development

Tag Archives: PMBoK

Risk is generally assumed to have negative impact. However, a ‘risk’ can also have a positive impact. PMBOK 4/e talks of positive risks and calls them ‘opportunities’. Given that most project managers only have a passing knowledge of managing risks proactively (our industry still seems to reward crisis management notwithstanding the fact that most often people who fix a crisis were responsible for it in the first place!), it is extremely likely that most such opportunities are wasted.

A risk is just a future event with probability of occurance between 0% and 100%. If such probability is 100%, surely that is a certainty, and hence can be put on the plan. If it is 0%, again it is a certainty and hence you can plan accordingly. Risks are also known as ‘known unknowns’ because we know about those events – just that we don’t know what it exact outcome will be. So, it quite likely that the outcome could be positive, and need not always be negative. Sample the following examples of events that could have a positive impact:

You have made an offer to a manager whose company is fast running out of cash. The grapevine has it that they might not get any funding, and have just weeks before they fold up. If that happens, there is a strong likelihood that the manager whom you have made an offer will join you. Even though this is a negative event par se for that company, but for you, that is a positive event.

Your competitor initially undercut his prices and won the bid, but now he is in the danger of being disqualified on technical grounds. His loss means business for you, and hence that is a positive risk.

You offer “no-questions asked product replacement warranty” within 60 days of purchase. You allocate 5% of your your operating margin. Your new product has proved to be a great hit among teenages, and is flying off the shelves, and you expect that cost of product replacement might be within just 2%, thereby improving your overall profit margins on this product.

You need to arrive at airport on-time, and your commute is through the rush hour. You leave home well in-time, but it is tough and go. However, there is a football match that evening, and it is likely that you find the traffic very thin – possibly because most people are glued to their TV sets.

Your new software provides a workflow for managing personal finances. An NGO needs a low-cost software to manage its micro-finance product, but best-matching product is out of their reach. Your product *might* meet most of the requirements, including being in the budget, if only they can tweak their workflow a bit.

You are in construction business, and learn that government is toying with the proposal to reduce duties on cement and steel by 20%.

A major competitor who is also a large employer in the city is likely to announce lay-offs.

Because of an early delivery of an input component, you might be able to shave-off weeks from your delivery schedule.

City administration is likelyÂ to announceÂ construction ofÂ a new Â flyover that will cut down city commute and decongest the downtown.

You are a tour operator and the international travel association is likely to name your region in “Top Ten Places to visit before you die” list.

Surely, these are simple examples, but demonstrate there are always positive risks in pretty much any project. However, we generally ignore them, and hence are not able to capitalize on them (we typically end up using the ‘accept’ strategy without even recognizing there might be other better ways of maximizing those risks or its returns). In addition to identifying positive risks, these four risk response strategies are identified to maximize the risk or impact of such positive risks:

Exploit – this strategy aims to eliminate the uncertainty associated with a particular upside risk by ensuring the opportunity definitely happens. Since this is a positive risk, the outcome is likely to be positive. However, there is an uncertainty to it, so if there is a way to eliminiate such uncertainty and make it a certainty, it ensures that you reap the benefits of such a positive risk. The idea is to virtually guarantee that a given risk becomes a certainty! Let’s consider some examples:

Suppose you are developing a prototype. If your customer likes it, your order book could be full for next few years! You have been diligent so far, and now have the prototype ready a week before delivery date. You are 70% sure that the customer will like your prototype, but instead of deliverying early, you decide to subject the prototype to even more stringent testing and analysis. Ideally, you will want to raise such probability to 100%, but that might not always happen. However, you put all efforts to make such event a certainty.

Another example – you have to make product release next weekend – if that happens, your customer might be able to roll out new services to its customers.Â You pull out some of the best technical folks on other projects and put them on this task to ensure that it happens.

Your biggest customer might be willing to give you 2x, or even 3x business if only you stopped working for his biggest competitor. You take the call to stop working with the competitor and make that event happen.

Share – Sharing a positive risk involves allocating some or all of the ownership of the opportunity to a third party who is best able to capture the opportunity for the benefit of a project. Â Here, the idea is to involves more players who also becomes stakeholders so thatÂ collectively raise the winnings. This strategy might be handy for some types of risks that might have have a positive uncertainty, but chances are that by yourself, you might by constrained in how much you can win. By involving other complementary players, you not only push the envelope, you get others to the game, make the game bigger and help everyone win, thereby also maintaining your own interest.

You are building a cool product that you expect to be a best seller. However, you lack the product design or marketing expertize to fully explout this opportunity. Instead of home-growing those capabilities, you decide to get experts on this project who are fired up with this challenge.

Apple uses this extremely well. By making its iPhone APIs available to larger developer community, it has been able to ensure that there is a dedicated army of developers constantly working to create highly innovate apps. This has resulted in over 100,000 such apps being available on iPhone!

You have developed a new intellectual property that promises to be a revolution. Instead of patenting it, you decide to open-source it to create a major eco-system of other vendors who might get interested to develop tools and apps around that technology thereby pushing the envelope.

Enhance – the idea is to increase the probability or impact of a positive risk. Increasing probability might not make it a certainty, but does improve the chances of the positive event happening. Improving the impact might not be necessarily associated Â with an increase in the probability itself, but might lead to a higher yield should the event happen. Of course, there is also an opportunity to do both of them simultaneously!

Let’s assume there is a cloud cover over a drought-hit region and there is a 20% possibility of rain. What do you do? You can utilize scientific methods like cloud-seeding to improve the possibility of rain to, say, 40%. In this example, you can’t increase the impact, but you are able to increase the possibility of that event.

This strategy is used quite well by retailers, especially in apparels industry. Studies have shown that home labels (or we can just call them the unbranded stuff) has a higher chances of being bought when carefully placed alongside branded apparels than standalone. This simple placement trick increases the chances of customers picking up home labels.

Companies and industry trade association hire lobby firms to influence lawmakers and citizens to look at some important regulation more favorably, thereby maximising chances of its adoption and eventual success.

While pushing for a new idea, sometimes you want to socialize it with a key voice in the organization, or perhaps get some industry references that generally extol benefits of that idea, thereby increasing the chances that your idea gets accepted.

This story illutsrates a great example of how one can both increase the probability and the impact simultaneously. I blooged about it in a different context, but you can read the story Are you helping your competitors succeed?

Accept – Accepting the opportunity is being willing to take advantage of it if it comes along, but not actively pursuing it. When I earlier said most of us ignoreÂ positive risks, we probably work in a passive mode, and pick up those low-hanging fruits. While this might not be a bad idea, in some cases, you might not want to incur the cost of ensuring that a certain risk does happen. So, this is like a zero-cost effort where if the positive risk happens, you are willing to grab it.

For example, you have just started out your consulting venture and are busy doing the legwork for it, and don’t want to take up an assignment for the coming month lest it interferes with your initial preparations. You hear about a business in distress that needs exactly the kind of consulting that you are offering, but decide not to actively pursue it. However, when they call you up, you are willing to take the call.

A competitor is likely to go out of business and you might benefit when that happens, but you don’t want to be seen as a bad rival trying to accelerate his downfall. So, you decide to take it easy and monitor the situation, but when that happens, you gladly step in.

You want to take homeloan. There is a chance that interest rates will come down in the coming quarter. Instead of waiting for that to happen (or, it might not even happen), you decide to take the loan right now. If the interest rates go down, you benefit.

Identifying and exploiting positive risks doesn’t require any special talent, but it does require a systematic effort to spot such opportunities. While negative risks are typically more dangerous and hence it makes great sense to avoid, transfer or mitigate them, positive risks could make a significant difference to your project’s chances of success. As we see in these examples above, many of these opportunities will fly under your radar if not proactively pursued. A holistic risk management strategy should always consider all types of risks and identify appropriate responses.

Project Management is perhaps one of the most fiercely debated and grossly misunderstood disciplines in the software field currently, hence let me throw in a disclaimer first: if you are a small team of experts and/or people well-known to each other (e.g., have worked together as a team earlier), and situated in a collocated fashion, doing a lot of ‘creative work’ that can’t be very ‘accurately’ scoped, let alone managed; you probably will find ideas of formal project management a huge overkill (on time, effort, money and might even seem to stifle creativity), and you might be better off considering ‘lightweight’ methods like Agile Project Management / Scrum in the context of software development (well, nothing stops you from deploying pieces of Agile / Scrum in a non-software context – it is based on common sense after all). Small projects, small teams can afford to define a process that exploits the tailwind:

A small and collocated team means more direct interaction among team members and lesser management overheads in formalizing projectÂ communicationÂ (e.g., project status reporting, team meetings, etc.). This reduces the time it takesÂ to collate, transmit and share important project information and also decreases the possibility of information distortion or confusion. A small team means there is high signalÂ to noise ratioÂ in team communications, is also leads to a better utilization of time spent in transmissing, receiving or digesting communication. Further, to schedule any event, one can always convene impromptu meetings around a whiteboard or around the coffee table without worrying about people’s already double-booked calendars or finding a place large enough to fit the team for the next meeting, and so on.

Having a group of experts means there is low(er) need for managerial supervision and people are generally ‘hand-picked’ for their knowledge, skills and abilities that could typically be ‘mutually exclusive, collectively exhaustive’. This ensures tight interdepency and very high mutual respect among team members. There is lesser ‘competition’ among team members and everyone knows that “united we stand, divided we fall” which fosters teambuilding.

For a small project, a large swing in any of the project constraints (time, cost, scope) could seriously and irretrievably impact the project in a downward spiral. If the work is new to the team, it could spell bigger trouble, especially if there is no way to do mid-course corrections. Executing projects in an iterative fashion helps shorten the feedback loop and give a chance to make necessary corrections to improve its ability to stay on-course and eventually hit the target. Additionally, if there is a customer involvement on these short iterations, the quality and value of these feedbacks could improve substantially lest any decisions are made that are hard to change if required.

However, if your project is anything more than a handful of people, takes more than a few months and entails issues like external dependencies with multiple vendors and ISVs (Independent Software Vendors), substantial technical and managerial risks, subcontracting / co-development, etc., you probably might improve chances of success using a formal project management methodology like PMBoK or PRINCE2 than without it. Agilists will argue and disagree with me that Agile / Scrum is not suited for large projects, but if you are new to Agile as well as to large projects, you might want to consider all options and associated risks – don’t believe in what worked for others, it might or might not work for you (remember the golden rule – we are all different), and your company might have a different set of constraints and tolerance to performance.Â

The size, complexity, criticality,Â and risk profile of a project, and organizational appetite for project risk and uncertainty, and organizational culture would generally determine the level and need of management control required, and hence one must always right-size the project management methodology based on the context. Both, PMBoK / PRINCE2 and Agile methods evolved in response to challenges seen in executing projects successfully. While PMBoK / PRINCE2 took the approach that projects most often failed due to lack right levels ofÂ management oversight, planning, execution and control; Agillists felt the key reason was the fundamental nature of software being a ‘wicked problem‘ that just could not be managed using an obsolete waterfall model of developing softwareÂ – it needed a better way to develop software in short iterations with very close-knit self-managed teams.

Without getting my loyalties needlessly divided betwen the two of these approaches, I believe there are merits in both the thoughts. I refuse to believe that any non-trivial project can be managed by piecemeal iterations that give no commitment whatsoever on the overall project performance, nor give any method to assess if the overall project is indeed on the right track (so, even if first few iterations are achieving the desired ‘veolcity’, what is the guarantee that subsequent iterations will also move at the same pace?). On the other hand, doing an iterative development is highly intiutive and very effective way to learn from past experiences to plan next steps, especilly on any non-routine project that is full of unknowns and assumptions. To me, these represent ‘mix-and-match’ ideas that one should pick up and apply wherever required, without getting baptized to the school of thought. I find most process wars have taken the disproportionate dimensions of falling just short of religious wars – you have to belong to one of the camps, and must talk evil about the other camp to be seen as a law-abiding corporate citizen of that camp. In life, we borrow ideas around us – our housing society, professional volunteer society we volunteer for, our kids playground,Â gardening, home improvement, nature, science, religion, other cultures…without necessarily converting to another faith or religion or society just because we like an idea that we want to borrow. So why should that be required in project management methods ???

I think this process war will be won by pragmatics. Those who take a position on extreme ends of the continuum and insist on always applying a particular style as the panacea might be in for a complete surprise because no two problems were created equal. A prudent approach is to evaluate all options and then decide which is the best response to a problem, as opposed to blindly follow a project management approach ‘religiously’.