October 21, 2013
Posted by on
Organisations are forever grappling with the demand of competing investments that give a varying range of benefits. How do they go about prioritising these? Most organisations use business cases as a means to filter out the projects that deserve funding from the ones that have little or no merit. This then introduces a secondary problem of spending a lot of resources on going through a business case, which will never see the light of day. How do you make sure weak business cases do not get all the way before getting knocked back.
Investment Logic Mapping (ILM) provides a good way to filter out some of these early investment dilemmas. This is part of the Investment Management Standard developed by the Victoria Department of Treasury and Finance in Australia. The main driver for the development of this standard was the number of complex investments that required compliance, but never articulated the benefits they were supposed to deliver. Effectively what started as a mechanism to shape individual investments in 2004 has now matured into programme and organisation levels – including refocusing organisations and monitoring benefits.
The theory behind the standard is quite simple. Rather than a complex set of tools, it is centred around three key concepts
- The best way to aggregate knowledge is through an informed discussion that brings together those people with most knowledge of a subject.
- The logic underpinning any investment (the ‘investment story’) should be able to be depicted on a single page using language and concepts that can be understood by the lay person.
- Every investment should be able to describe how it is contributing to the benefits the organisation is seeking.
In Victoria it is now mandatory for most significant investments. In New Zealand the State Services Commission (SSC) mandates the use of ILM for High Value or High Risk (HVHR) projects as part of its Better Business Cases initiative. It must be remembered that ILM on its own is not the tool that will drive the investment. It is a tool to eliminate initiatives which lack merit.
I have just recently undertaken an Organisational ILM as part of a strategic review for an organisation. I have found it an excellent tool to bring out the challenges in an open forum and to agree on strategic responses. The two hour session was perfect to get enough senior leadership in one room to work through the organisational challenges. I also found it a good use of senior stakeholder time, as they are busy people and often trying to agree a course of action individually with all of them is a significant barrier to change programmes.
If you have used ILM before, I’m keen to know your experience. The only thing I had forgotten is being on your feet facilitating for two hours, while everyone else is seated discussing and having refreshments is quite tiring.
July 23, 2012
Posted by on
I often see debates on project management forums on LinkedIn, blogs and even at the water cooler around the office regarding what project management methodology is best. I have often wondered about the wisdom of such discussions. The two that are always compared are PMBOK (Project Management Body of Knowledge) and PRINCE2 (Projects in Controlled Environments Version 2 – 2009). One such discussion with a fellow professional led me to have a little bit of a think.
PMBOK Process Model – Credit: PMI
I will declare my hand at the outset. I have squarely gone for certification route through the Cabinet Office products for project, programme and service management (PRINCE2, MSP and ITIL). This is not necessarily because I was convinced these were the best frameworks, but my assessment of what the market around me considered more valuable. With the Australasian market following that of the United Kingdom and Europe, it made more sense for me to pursue this line, than the PMBOK based certifications from the Project Management Institute (PMI) in PMP and PgMP.
PRINCE2 Process Model – Credit: ILX
Genesis of PMBOK is in the engineering sector in North America. I can see that has led to significant emphasis on the tools and techniques of how to manage projects. I find it has excellent guidance in what it calls the knowledge areas. For example, it provides techniques for monitoring and controlling projects through Earned Value Analysis (EVA), estimation through the Program Evaluation and Review Technique (PERT) analysis. It elaborates on Precedence Diagramming Method (PDM) to identify sequencing and various lag options. It has tools and techniques for scheduling using Schedule Network Analysis, Critical Path and Critical Chain, discusses Resource Levelling and What-if Scenario Analysis. Tools and techniques is where PMBOK has it all over PRINCE2, which goes very little into the skills required to be a project manager.
PRINCE2 began with a desire to control capital IT projects in the United Kingdom. Interestingly, a methodology that began in such a technical sphere has very little in the form of guidance through tools and techniques. PRINCE2 is very strong on project governance. Its strength is in the focus on the continued business justification through a living Business Case. In managing by exceptions, it removes the temptation for death by project reports, but at the same time provides a mechanism for escalating when necessary. In managing by stages, it builds in regular reviews of whether the business case the project is trying to deliver to be still valid. The biggest outcome of this is the assertion that a project unlikely to deliver to business case is better cancelled than meandering along. Project structure and principles also ensure projects are delivering to strategic initiatives of the organisation.
I have previously posted about the challenge in implementing PRINCE2 as the project framework for supplier organisations. I have used the principles rather than exact implementation as described in the text. It is much easier to take the PMBOK tools and techniques and implement directly into your projects in a supplier context. PRINCE2 however does a better job of risk identification and management techniques with the various response options and planning. There are also pros and cons about the accreditation methods. PRINCE2 is often criticised for allowing potential non-practitioners to get certified because of its examination only method. In order to get a PMP accreditation, you have to go through a significant effort to prove hours under the belt. That is a good idea. But you have to accumulate Professional Development Units (PDU) to stay current. I have seen plenty of mickey mouse outfits dispensing PDUs like confetti to have any meaning to these.
When I consider all of this, it appears a futile argument from those in either camp. In my view the best option is to use PRINCE2 to understand “how” to run the project and PMBOK for guidance on “what” to do in the specific scenarios. The question is not one of PMBOK or PRINCE2, but how to use both in your projects.
March 26, 2012
Posted by on
Longer projects run, higher likelihood of project failure. One of the moves in recent times to reduce complexity in software development is to adopt Agile delivery approaches. The desire to build confidence and leave tangible benefits even if projects are cancelled has provided further impetus to adoption of Agile practices. This approach has delivered good outcomes for teams that work in in-house and product development teams. However, challenge remains in successful adoption Agile practices in contracted deliveries.
It is rarely the willingness of the project teams or suppliers that is the barrier, but the way organisations work. A quick review of how most organisations initiate projects will highlight this. In most organisations operational staff will identify areas of improvement. Organisations have processes to provide feedback to management to achieve this. Management then compile business case, which is then reviewed and approved by the organisation. It then moves through the procurement cycle, supplier selected and contracts agreed. These contracts are on the basis of deliverables (outputs in PRINCE2) from the project, rather than benefits.
Let us now review the consequence. The project is set up with A, B and C as deliverables. As the project starts, it becomes clear that modifying B will provide far more benefit, even if C is dropped off altogether. In an agile project, the customer is able to provide immediate feedback and the product backlog would be adjusted accordingly. Here the project team consists of suppliers who are under contract to deliver C. They cannot alter the required deliverables. The project team from within the organisation is also not authorised to make this adjustment.
As you keep moving up the organisation challenges still remain. Project governance is set up to hold people accountable for the delivery. Benefits are more difficult to quantify than outputs. Therefore the culture is usually to hold people accountable for the outputs. Modifications to business cases are usually treated as acknowledgement of omission, rather than as an evolution of the project.
So why this inertia for reviewing the deliverables in order to extract the best benefit? Consider what else the people in charge of procurement acquire for the organisation. For most things they are able to show something tangible – an air conditioning unit, an executive table, a new building. Other things they procure are services that are usually measured in time – 3 weeks of consulting. Software development is somewhere in between. You have time, the deliverable is something abstract and it is difficult to judge whether you got what you had asked for – a lot of grey areas. The people to judge is often not the ones that approve the procurement or control them. Auditing the procurement is therefore difficult terms of benefits. As a result you end up with controls on outputs.
In order to successfully embrace Agile delivery practices it is imperative that procurement and auditing methods in the organisation is geared towards measuring benefits, rather than outputs.
March 5, 2012
Posted by on
Project management principles are the same world over. However, the application of those principles vary widely depending on the type of organisation you are in and the type of external pressures you face. Here I use the word external to mean influences outside the project, rather than the organisation. PMBOK and PRINCE2 contend that the Project Manager runs the project on behalf of the governance team or the project board, so the decision on project selection and business case rests with them. Most organisations will use the experience of a Project Manager to determine the business case.
I work for a niche technology company that predominantly provides professional services and software development. Recently we have moved into the product sale market. One constant pressure we face is to limit costs of professional services in order to land a product sale. This is not unique to our company. There is always a judgement call between the appetite for cost the customer has in determining the final price. Regardless of the pressure, the effort required to deliver the outcome the customer is after does not change.
When there is internal pressure to reduce estimates, the Project Manager can negotiate with the sales staff to reduce scope as a trade off. That does not always work, as professional services companies are rarely in the position of setting the agenda. More often than not, they are responding to a demand based on gaps in the customers core staff. Usually everything is a must have. The question at this point becomes not a project management one, but a strategic one for the company. The project may be desirable despite possible overruns in the current project. There may be future projects, or may provide foot in the door to a particular segment of the market or may be a key reference customer. It is the Project Manager’s responsibility to quantify the cost appropriately, so the management can make an informed choice about how much risk they wish to carry. Simply adhering to the wishes of the sales staff is a dangerous game to play.
A second external pressure that constantly challenges project estimates is the pricing of competitors. This is a more difficult proposition to deal with, as the parties are outside the organisation and you will never have the full facts to compare your estimates. The opposition may be desperate and willing to undercut any estimate you provide. Equally, they could be significantly underestimating the risks and deliverables. The key here is to not look at your competitors on a project basis. Look at the pattern over a period of time and see if they are making a success of those projects where you are being undercut. If they are, then challenge your teams to sharpen their estimates. Be mindful though, there will always be cowboys in the market and clients willing to make to do on shoe strings. If that is the case, move on. Choosing to compete at that end of the market will be at the cost of reputation and professional satisfaction.
A third challenge a project manager faces is trying to recommend when a project should be terminated. Usually business cases are made to start a project. It is less common to continually validate the benefits sought in the business case as the project is in flight. Things can get complicated if it is a pet project of someone higher up in the organisation. It is imperative that a Project Manager is aware of what benefits are expected out of the project. That will allow for quantifying accurately if the benefits sought can be achieved based on realities of the project. Nothing is black and white in projects. That is why they are temporary and higher risk than Business As Usual activities. In some cases the organisation may decide risk to reputation is worse than loss in a project.
Projects are inherently risky and pressures are a fact of life. How we deal with the risk and how we quantify it to management is where a good Project Manager stands out. It is the organisation that makes the decision, but it is the Project Manager that provides the analysis to facilitate that decision.
May 28, 2011
Posted by on
I went to the New Zealand PRINCE2 User Group meeting on Thursday. The group promotes a collegial approach to the Project Management body of practice. The topic of the gathering was Business cases in PRINCE2. This was an interesting discussion with a specific example of a project where a tertiary education provider is undertaking a business case to establish whether to build high quality student accommodation to attract foreign students. Read more of this post