As a project manager, you will often be called upon to make decisions. How you make them really shows the difference between the amateur and the Project Management Professional (PMP)^®. In your early days, you probably relied on gut instinct or made choices based on nothing more than Option-1 has a prettier cover than Option-2. But, now that you have your PMP^® certification, you must ensure that each decision you make is based on objective analysis.

On this page:

• Using Expected Monetary Value (EMV) Analysis for Decision Making
• Costing the Options: Make or Buy Decision
• Considering Additional Factors: Total Cost of Ownership

Using Expected Monetary Value (EMV) Analysis for Decision Making

Expected Monetary Value analysis is an excellent tool to help you make decisions. Although introduced in your PMP^® training as part of quantitative risk analysis, it can also help in all sorts of decisions. However, it is important to realize that this technique organizes information for you; it does not provide you with the raw data that underpin the decision.

For instance, suppose we are a software company and have identified a need for a particular type of program. We will only use this internally, so there will not be any revenue potential. We have people in-house that can do this work, but other software companies have this type of product out there on the shelf. So we must make the classic decision: whether to make or buy.

We can use a Decision Tree to frame our analysis:
 

“Make or Buy” is the decision we have to make. This is the “Decision Definition” according to Guide to the Project Management Body of Knowledge (PMBOK^® Guide). The black square indicates the “Decision Node”. To the right of the decision node are the options we have: “Develop New Software” or “Purchase Software Package”.

Costing the Options: Make or Buy Decision

What we need to do now is cost the two options. This is more difficult than it looks. Some components of the cost are easy to specify and they represent definite outlays. In this example, the cost of purchasing the package should be well defined. However, before we can provide any estimate of the build cost, we need to do some planning. We need to determine how many people will be needed to work on this for how long.

This level of analysis will give us two figures and we should opt for the lower of the two. So if we determine that it will cost €5,000 to develop the software ourselves and €1,000 to buy it off the shelf, then the decision is obvious.

Or is it? This is the sort of simplistic analysis that gets unwary project managers into trouble. We need to assess the total cost of ownership. How long will we need this software for? How much are the vendors charging for support contracts? What are the odds that we will need this support? What are the odds that the package will actually do what we want it to do? And what are the consequences if it fails to live up to expectations?

Similarly, if we go down the build route, what are the opportunity costs of investing in this project? Would our people be better employed on other tasks? Similarly, how good is our estimate? Suppose half of our development projects overran their budgets by an average of 20%, how will that affect our decision?

This sort of thinking leads us to add “Chance Nodes” to our Decision Tree diagram:
 

Let us suppose that there are no opportunity costs – the developers are not being taken off other projects for this – in fact this little project will keep them usefully employed before their next big assignments. Then the only extra we need to worry about is the likely cost overrun, which would bring the expected cost up to €6,000. There is an even money chance that this will overrun (i.e. a probability of 0.5) and the average overrun in the past has been 20% (€1,000 in this case). So the likely overrun is multiplied by its probability and added to the original figure.

Considering Additional Factors: Total Cost of Ownership

The advantage of building the product in-house is seen when it comes to support. We can include the product in with the other products we provide and look on support as part of the overheads we factor into our budgets. If this is not the case, then support would have to be explicitly calculated and included in the development budget. However, the buy decision means that support is a serious consideration!

With any product, there is a very real chance that it will not work at all. This risk needs to be mitigated by investigating the product thoroughly before buying. It is amazing how much software is purchased and never used because of some factor. For instance, a product might seem ideal during a demonstration, but falls completely flat when asked to process large amounts of data. In our example, we reckon that there is a one in four chance of this happening and our contingency plan is to develop in-house. To accommodate this, we need to add 0.25 of €5,000 to the buy option.

Another possibility is the need for support. Many software companies price their products keenly, but made their money on service agreements. Here they promise updates and bug fixes. This is very attractive if this product will be in service for a long time. In our example, the maintenance contract for one year is €500. If we only plan on using this for a year (or less), we could gamble that we will not need support. However, we can always sign up for a year’s agreement if we get into trouble. Showing all this on the Decision Tree gives:
 

Now we can calculate the relative costs of the two options, as follows:
 

Thanks to Expected Monetary Value analysis, we now see that the make or buy decision is not as clear cut as it looked originally. In the normal course of events, opportunity costs could cripple the case for building in-house – for instance, the team could be set to work on a project that earns revenue instead. Another factor that we did not consider is Net Present Value. If the software package was very expensive, the initial outlay could make the gradual consumption of resources of the build option more attractive – especially when the banks are not lending.

In both cases, it is vital to consider the total cost of ownership. In the example, if we opt to take out a maintenance agreement, we will spend as much on maintenance as on the original product in two years. We also conveniently assigned in-house maintenance to a company-wide overhead. If somebody needs to be made available for support, that cost should be factored into the analysis.

The important thing to realize though is that a PMP^® makes decisions based on objective fact and not on appearances. Although this example shows that the initial figures were enough to make the decision, further analysis pushed the two figures closer together. In other cases, detailed cost analysis will prove that books should not be judged by covers.

If you would like to learn more about Decision Tress and other project management tools and techniques as well as the various certification options open to you, please visit our training page. Our project management courses are being delivered online using our virtual classroom, so you can take one from the comfort of your own home. To get more details, please contact us directly.