If there is anything we can and have learned from the Global Financial Crisis is that what we were taught at university in the 80s was blatantly wrong. The over reliance on mathematically elegant Macro Economic models at the expense of the necessary immersion in what makes the REAL world work. I can recall with some sense of apprehension the aesthetically beautiful graphical models showing how market forces will emerge to push markets into an efficient equilibrium. No one considered, let alone elaborated, on the impact of behavior, attitudes and – most importantly – the very lessons we can learn from observing and interpreting past events.

Reflecting on our very own domain – project management – we can, and indeed should – ponder the possibility that perhaps the way we train and educate aspiring project managers is partially or totally flawed.

Unlike some other professions (and ignoring for a moment the potential discussion around whether or not project management is a profession), one can become a project manager having taken a number of alternative paths. I, for instance, have started my professional life as an economist, have then become a software programmer, a systems analyst, a business analyst and then a project manager. My project management knowledge and experience evolved through observation, on-the-job and formal training and, at some point in time, through the codification of that journey using the PMBOK / PMP accreditation process.

What troubles me in the path I have taken is the fact that it is superficially tilted towards the application of processes and the reliance on ‘best practices’. The PMBOK, for instance, is rampant with linear processes coupled with supporting tools and techniques. It does not force you to use them all or follow them dogmatically but it certainly suggests that in the application or execution of an average project many of these processes, tools and techniques would be a useful thing to consider.

And here’s what is wrong with this approach:

It lacks explicit and direct attention to the body of evidence and case studies researching the reasons for failed projects. It makes no explicit attempt (except for the superficial incorporation of ‘Organizational Process Assets’) to formalise a body of knowledge for practitioners to explore, evaluate and learn from other people’s successes and failures. It totally lacks any retrospection and constant self-evaluation.

Furthermore it lacks context or any appreciation of situational circumstances. Think Cynefin, for example, and you will immediately see that the execution of projects in any one of the four Cynefin quadrants would be completely different and require different skills, different approaches and different tools and techniques. If you approach project management as a linear process you will fail before you even started your journey.

So the next questions we need to look at are:

What steps do professional organizations (like the PMI, and others) take to make sure that certification is indeed relevant and takes into account the proper parameters necessary to be an effective and well-informed project manager (incorporating such knowledge areas as ethics, history of project management, behavioral economics, etc)?

and…

What role do universities and other educational institutions play in ensuring the correct knowledge is taught?

Only a collaborative approach between education providers and accreditation institutions can close this gap.Universities and other institutions need to make sure that project management is being taught not as an engineering course but as the new economics ought to be taught, taking into account the various disciplines necessary to produce a ‘ready to go’ project manager. Accreditation organizations need to reciprocate and adapt by insisting on having these parameters reflected in their accreditation curriculum.

Not implementing the above approach will not be disastrous it will just mean that as a collective we will continue to be mediocre.

Think about it!

07. July 2014 · 5 comments · Categories: Agile

The founding fathers of the modern Agile movement (don’t think there were any ‘mothers’ there), through the release of their Agile Manifesto, have put in motion a process of change in the Software Development world (notwithstanding Terry McKenna‘s paper titled “Agile is Not the End-Game of Project Management Methodologies“). A closer examination of the changes that transpired since makes it obvious (I hope) that the success of Agile was due not just due to the incorporation and injection of Agile concepts into software development processes, attitudes and rituals but also due to the corresponding adaptation of Lean principles, without which the Agile benefits would be (most likely) far less impressive.

It is the Lean thinking that allows the adaptation of Agile practices into non-software projects. The focus on value, the concentration on managing an efficient flow of work, fast delivery and (even) faster failure; these are all principles that can (and should) be used in the running of any project, software or not. Agile ceremonial are adequately useful to the running of non software projects. Daily (or otherwise periodical) stand ups, Retrospectives (aimed at fast learning and immediate corrective action) and value driven delivery focus are all practices that can be applied, successfully, and easily into non-software projects.

One last comment. While I make this claim, that agile and lean practices can be applies to non-software projects, I have to qualify it with the following domain related comment: My main experience in running agile projects is in technology domain. I have, however, have experienced the adaptation of these principles and methods into projects where the deliverables were business processes, operational instructions and business strategies. And just in case you wonder, not sure how that would be implemented in construction projects.

Think about it!

04. July 2014 · Write a comment · Categories: Agile

Few weeks ago I had the pleasure of attending the Agile 2014 Conference in Melbourne. With the overall title for the conference being “embrace disruption” I was naturally excited about the opportunity to hear from various thought leaders of their take on the tools we can positively use to deal with the inevitable change we are all facing.

In what to follow I will summarize my key learning and observations from some of the sessions I have attended:

In a talk titled “Unleashing the Full Potential of Your Agile Teams”, Dipesh Pala made the observation that the conditions necessary to achieve a happy team are similar to those needed to keep individuals happy. Those, he asserted, are dependent on a sense of achievement and this does not necessary require massive, gigantic, overreaching ones as small wins are sufficient to foster this sense of achievement. But making progress, while important, is not – on its own – sufficient to guarantee this sense of achievement. This needs to be associated with progress achieved via the execution of meaningful work. It is this combination of progress and meaning that fosters the sense of achievement, and it is this sense of achievement that is the pre-requisite to the emergence of happy teams.

Happy Team

John Sullivan, a Product Delivery Manager – Business Division, MYOB, spoke about the Agile journey of the development team in MYOB. The core question he addressed was the challenge of transforming their development team to Agile just to confront a degradation in the quality of the product delivered to the market. Or more succinctly, what do you do when you follow the Agile principles but your product delivery if lacking to the point where the market is voting you out of business? The answer, a la John, is simple: Change the focus of your teams from Agile to Delivery. The purpose of adopting agile practices is just the means but not the end. If you focus on the ceremonial aspects of Agile and forget that these are just there to support your end goal – that is the delivery of quality marketable products to the customer – then you’ve missed the point.

Focus on Delivery not on AgileIn “Lean Entrepreneur in the enterprise”, Brant Cooper indicated that there are two questions that kill innovation: 1) What’s the ROI? and 2) When will we see it? Innovation, according to Brant, is a product of a long journey that start with Disruption and ends, after a few twists and turns with a Sustainable product. This Disruption is the playground of Innovation as it is innovations that create the environment resulting in changes to current practices. While the journey from Disruption to Sustainability is a treacherous one, its fundamentals are pretty well known and it all starts with an experiment. The process of innovation is about a journey of experimentation, of trials and of learnings through failures. If you are not prepared to entertain failures and are not willing experiment you are not ready for innovation.

InnovationGeoff Apps, Director of Engineering in Zappos, gave an interesting talk titled “Holacracy at Zappos – how do you manage to deliver value when ‘anything goes’?”. His talk expanded on the journey his company has gone through as it went through the adoption of Holacracy as its operating (or rather Way of Working) model. The Holacracy concept revolves around the creation of purpose driven, self-organised and self-energised teams (known in Holacracy is ‘Circles’). Circles operate in accordance with the Holacracy Constitution and employees are assigned to various circles where they might be playing different roles in each. While no notes were provided by Geoff you might want to check the following article in Forbes which generated an interesting public debate earlier this year.

Holacracy CirclesThe last session I will review here is titled “Impact Mapping – Making an Impact over Shipping Software” by Em Campbell-Pretty. Impact Mapping is a visual technique that attempts to address four key questions: 1) Why you want to do (what ever it is that you want to do) – i.e identify your Goals; 2) Who will do it – i.e. identify the actors; 3) how would that be done – i.e. what are the impacts of what we plan to do; and 4) What will be done – i.e. what are the deliverables that will be produced. The impact of these questions (and associated answers) only becomes apparent when you draw them on a canvas and turn them into a visual board through which all relevant participants are able to view, comment and generate a common and shared understanding pertaining domain under investigation.

Impact Mapping

And a few general comments:

Given the considerable time that now passed, since the publication of the Agile Manifesto, some speakers have taken the opportunity to reflect on the journey and address some of their own observations on the trends and events that transpired since. One comment was made about the apparent attempt to ‘codify’ Agile, i.e. to cement the principles and ideas into a set of ‘do this’ and ‘don’t do that’ processes and procedures. This, generally, was frowned upon with the note that being agile and implementing agility is about being adaptive, experimental and open to change. The point of ‘doing’ agile and of ‘being’ agile is to deliver value to the customer (i.e. to DELIVER) so, in that sense, it is a means to an end – a point that should not be lost on agile practitioners.

Overall an entertaining and thought provoking conference.

Think about it!

 

 

Reading some of the conversations around the need to adopt a more exploratory and adaptive approach to estimation (aka #NoEstimates) made me realize that there is something deeper going on here beyond just objecting to the delivery of estimates on ideological grounds. While the arguments against estimation are grounded in seemingly rational and logical observations, they represent, at a deeper level an ideology and a way of thinking that warrants serious contemplation.

Being a member of a team, any team, carries with it some responsibilities. If you are a member of a national soccer team and you happen to bite one of your opponents, this activity reflects on you and is consequently impacting your team. This is why when we talk about the members’ function within the team and within the organization we often refer to it as their ‘role and responsibilities’. Having a responsibility is therefore a part and parcel of your role – one cannot exist without the other. The combination of a role and its responsibilities is a sign and measure of being accountable. In this context, accountability means having a skin in the game, being directly and personally involved in the success or failure of the organization.

Providing estimates for a prescribed activity is a method by which the organization utilizes one’s knowledge, experience and expertise in order to make an investment decision. When you make a claim that the decision maker will be better off proceeding without this estimate you very much proclaim that you wish to NOT have any tangible stakes in the decision to proceed. You wish to NOT be held, even partially, accountable or responsible to whatever transpires. If all goes well you are happy to bask in the glory of the success but should things go pear shape…well, not your fault!

Think about it!

Couple of months ago I was approached by Geoff Crane, a blogger and a Professor of project management at Durham College, to assist with the following request:

I teach project management at Durham College in Ontario. My first batch of students will graduate next month and as a gift I’m looking at putting together an eBook for them…

What advice do you have for project management students fresh out of school who want to break into the discipline?

This is a burning issue for most of them–they’re really looking for advice. As someone with a vested interest in the field, I know your insights will be valuable.

The fruit of my (and other 51 contributors) labor has been collated into a fantastic eBook titled 52 Tips to Break Into Project Management (see also on Slideshare). You can also read my own response below:

Project managers are usually seen by society, and unfortunately by themselves, as being the delivery arm of the organization. As such, one might conclude, their role is not dissimilar to that played by the hand in the human body. The head is where the scope and the vision are being formulated and these sets of governing concepts and rules are then being transmitted to the hand to carry them out. The hand, in this crude analogy, has no room – nor any capacity – to play a devil’s advocate and challenge the brain for the validity of its decisions and as such is expected to blindly follow the instructions received and carry out prescribed mission.

Being a project manager requires one to deliver, to meet objectives, to produce the results, to follow the path chartered for it by its stakeholders. An aspiring project manager might think, not unexpectedly, that he or she has no role to play in validating the morality – in the widest possible sense of this term – of the actions it is asked to lead. Regardless of the domain in which you will find yourself, you will always come across (provided you keep your eyes opened to such situations) where you will need to validate your actions against your moral compass. These might be internal to your project – like, for example, the way you tread your team, the way you respond to pressure and the way and methods you use to communicate with peers and subordinates – or external – where you might turn a blind eye to the impact of the project you are managing on the environment, on people and on society as a whole.

Having been in this game for some time now I lament the fact that in my earlier days no one introduced me to the need to evaluate my actions, all my actions, against my value system. Had I been alerted to this possibility I might have, and quite likely would have reacted differently to some earlier circumstances where I was not yet fully aware of my options and assumed, incorrectly, that my job is to deliver – no matter what.

Think about it!

The Cynefin framework identifies five domains within which systems and environments can co-exist. In summary the five domains are:

  • The ‘Simple‘ Domain – characterized by clear cause-and-effect relationships, with well-defined rules of engagement that call for the use of best practice approaches.
  • The ‘Complicated’ domain – where the relationships between cause-and-effect are not straight forward but are discernible subject to some level of analysis or investigation with the application of expert knowledge.
  •  The ‘Complex‘ domain – where the relationship between cause-and-effect can only be perceived in retrospect
  • The ‘Chaos‘ domain – where uncertainty is abound and no discernible cause-and-effect relationship are known to exist.
  • Disorder‘ – when no clear realization exists regarding the state at which the situation is and where no clear action can be taken due to conflicting views and complete lack of leadership.

When tying the concept of software development estimation with the Cynefin framework one has to consider (or rather ‘sense’) in which domain the system and the environment are and, based on that assessment, tailor the estimation process to account to that situation. The situations most likely to be present at the outset of the estimation process are as follows: Cynefin combinations Some of the objections to carrying out estimates touch on the variability (or rather uncertainty) associated with the state of either the System or the Environment. The Cynefin Framework recognizes the difficulty associated with managing complex situations and suggests an approach to effectively get them managed. Tackling complexity requires resident knowledge about the system and its environment and, more importantly, requires adaptation and openness to learn about them. Experimentation management is the key to overcome the fear of tackling the unknown. Rather than adopting an attitude of ‘it cannot be done’ I would suggest that an attitude of ‘let’s put in a place a process of experimentation so we can tackle the unknown’ would better serve the needs of both those delivering the estimates and those requiring them for business decision-making. Think about it!                       aaa

Introduction

The fourth installment in the ‘The Case for the Business Case‘ focuses on a review of  a 2013 paper by Professor Egon Berghout and Associate Professor Chee-Wee Tan, published in Information & Management, and titled “Understanding the impact of business cases on IT investment decisions: An analysis of municipal e-government projects“.

But first a recap:

In the first part of this series I elaborated on a model suggested by Jeanne W. Ross and Cynthia M. Beath; focusing on the association between two dimensions: Technology Scope and Strategic ObjectivesTechnology Scope covered the investment spectrum between Shared Infrastructure and Business Solutions and Strategic Objectives covered the spectrum between Short Term Profitability and Long Term Profitability; resulting in four investment areas categorized as: Renewal, Transformation, Process Improvement and Experiments. The authors suggested that organizations need to make consciousness decision as to what portion of their investment allocation will be allocated to each of these categories and then evaluate any request for funds against that allocation.

In the second part I introduced an approach suggested by Professor John Ward, Professor Elizabeth Daniel and Professor Joe Peppard, where they were suggesting a method which will enable the organization to better understand the stated benefits expected from executing its IT investments. This approach was a result of evidence suggesting that many business cases either exaggerate the expected benefits or lacked elaboration on the business change required to have them realized.

In the third part I introduced a model developed by Peter Weill and Sinan Aral where they make the observation that most organizations make IT investment decisions along a range of four categories; being Transactional, Information, Strategic and Infrastructure.

Understanding the Impact of Business Cases on IT Investment Decisions

Taking as a starting point the perspective that having a good business case is a fundamental requirement for any solid (and subsequently successful) IT investment, the authors set out to formulate an answer to the following two research questions:

  1. What are the constituent elements of required to assist in the development of rich business cases for IT investments; and
  2. Do these elements add value to IT investment decisions (to the point that they contribute positively to the subsequent success of these investments).

To derive an answer to the above question, the authors reviewed existing business case development methodologies and by comparing and contrasting their proposed components they identified a super-set of components, the validity of which they then verified against actual business cases (collected from e-government projects from 38 Dutch municipalities) with a view to confirm the level of correlation between the incorporation of these components and the level of initial cost estimate’s accuracy attributed to these business cases.

The literature review revealed nine business case constituents components that are pertinent to the evaluation of IT investments; and these were subsequently grouped into three categories: organizational constituents, technological constituents, and project constituents; as shown in the diagram below:

Business Cost Constituents

The characterization for each of the analyzed business case constituents is defined in the table below:

Constituents of business cases and their corresponding characterization

Constituents of business cases and their corresponding characterization

Having analyzed the inclusion of these constituents in actual business cases, and determining the correlation between the incorporation of each of these constituents and the level of accuracy of the initial cost estimates for each of their associated projects, the authors conclude that:

Our empirical findings indicate a significant, positive relationship between the number of business case elements and the ‘Initial Cost per Citizen’ for the e-government projects. This implies that the inclusion of additional business case elements from our developmental framework translates to improved cost estimates for IT projects. Conceivably, it is advisable to develop detailed business cases because they will safeguard against overoptimism on the part of decision makers and provide a more precise picture of the costs to be incurred…

The authors further determine that while there are nine general constituents that are prevalent (to various degrees) in the various methodologies, some have a greater impact on the accuracy of the initial cost estimates than others.

We further discovered that different categories of business case elements have distinct impacts on the initial cost estimates of IT projects. Of the three categories (i.e., organizational constituents, technological constituents and project constituents), business case elements associated with project governance (i.e., ‘Project Planning and Governance’, ‘Cost Appraisal’, ‘Risk’ and ‘Stakeholders’) exert the strongest influence on the initial cost estimates. Conversely, organizational and technological business case elements do not affect initial cost estimates..

What the above means is that while there are a number of contributing factors to the creation of a successful business case, not all directly impact or affect the accuracy or correctness of the initial cost estimate.

Some Final Thoughts

The conclusion that a robust business case is a positive contributor to a positive realization of IT Investments is not a revolutionary idea. Nevertheless it is a valuable reminder that an up front investment in producing a rich business case, consisting of a relevant set of supporting information is, at the very least, a precursor and a pre-requisite to an early (and more accurate) estimation of the expected costs. Considering in the context of public debates surrounding the validity and usefulness of producing project estimates, this study makes an unequivocal observation that while the long-term success of IT Investments is closely tied with its initial cost estimates, the determination of these estimates requires some up-front work and, should that work be carried out, it is likely to result in positive results.

Think about it!

 

Introduction

The third installment in the ‘The Case for the Business Case‘ focuses on a review of  a 2006 paper by Peter Weill and Sinan Aral, published in the MIT Sloan Management Review, titled “Generating Premium Returns on Your IT Investments“.

But first a recap:

In the first part of this series I elaborated on a model suggested by Jeanne W. Ross and Cynthia M. Beath; focusing on the association between two dimensions: Technology Scope and Strategic Objectives. Technology Scope covered the investment spectrum between Shared Infrastructure and Business Solutions and Strategic Objectives covered the spectrum between Short Term Profitability and Long Term Profitability; resulting in four investment areas categorized as: Renewal, Transformation, Process Improvement and Experiments. The authors suggested that organizations need to make consciousness decision as to what portion of their investment allocation will be allocated to each of these categories and then evaluate any request for funds against that allocation.

In the second part I introduced an approach suggested by Professor John Ward, Professor Elizabeth Daniel and Professor Joe Peppard, where they were suggesting a method which will enable the organization to better understand the stated benefits expected from executing its IT investments. This approach was a result of evidence suggesting that many business cases either exaggerate the expected benefits or lacked elaboration on the business change required to have them realized.

Generating Premium Returns on Your IT Investments

The paper addresses two points:

  1. Most organizations make IT investment decisions along a range of four categories (and this will be the focus on this post); and
  2. Gaining a better return on the IT spend requires organizations to exhibit a certain set of practices and capabilities – and the authors refer to organizations that exhibit these practices and capabilities ‘IT Savy’. This post, however, will not focus on this point as it is not directly contributing to the discussion concerning the way organizations structure their approach to approving IT investment requests.

In an approach somewhat similar to the one we already encountered in Jeanne W. Ross and Cynthia M. Beath’s article, the authors suggest that most organizations make IT investment along four broad classifications:

Considering IT Investments as a Portfolio

 

Transactional Investments:

This are investments that “are used primarily to cut costs or increase throughput for the same cost“.

Information Investments:

These are used to “provide information for purposes such as accounting, reporting, compliance, communication or analysis“.

Strategic Investments:

These are used to “gain competitive advantage by supporting entry into new markets or by helping to develop new products, services, or business processes“.

Infrastructure Investments:

These are funds allocated to the creation of “shared IT services used by multiple applications…depending on the service, infrastructure investments are typically aimed at providing a flexible base for future business initiatives or reducing long-term It costs via consolidations”.

The authors acknowledge the fact that for any single project, the associated investment can spread over one or more investment types, meaning that when requesting funds towards making an IT investment, that – most often – will serve more than just one purpose and thus the expected outcomes and benefits are likely to be spread across different investment domains.

They further suggest that this portfolio allocation approach “underscores the importance of how organizations use technology instead of focusing on the technology itself“. This puts the responsibility on senior managers to have a clear vision about what is it that they want to achieve from their IT investment. The paper further suggests that the business value derived from each investment classification is different. For example. transactional investments are likely to result in lower cost of goods sold, while strategic investments are likely to result in greater innovation and provide a platform for future growth, etc.

Some Final Thoughts

The importance of this paper is not so much in the actual model if suggests for IT Investments’ classification as much as in the principle it establishes. Given the limited pool of funds available for IT Investments, organizations ought to create a strategic view of how they want their funds to be split in order to achieve a balance between their various competing needs  - a sentiment firmly planted in the discussion made in the first review in this series. Unlike the first review, the classification system proposed does not explicitly recognize the need to allocate funds to ‘experimentation’ (unless this can be bundled under Innovation).

 

Introduction

In the first part of this series I elaborated on a model suggested by Jeanne W. Ross and Cynthia M. Beath; focusing on the association between two dimensions: Technology Scope and Strategic Objectives. Technology Scope covered the investment spectrum between Shared Infrastructure and Business Solutions and Strategic Objectives covered the spectrum between Short Term Profitability and Long Term Profitability; resulting in four investment areas categorized as: Renewal, Transformation, Process Improvement and Experiments. The authors suggested that organizations need to make consciousness decision as to what portion of their investment allocation will be allocated to each of these categories and then evaluate any request for funds against that allocation.

Building Better Business Cases for IT Investments

Today’s literature review will provide an overview of an approach suggested by Professor John Ward, Professor Elizabeth Daniel and Professor Joe Peppard, in a paper titled “Building Better Business Cases for IT Investments” (the paper was originally submitted for publication to the California Management Review in September 2007, though I could not find the published article in the journal itself).

The focus of the paper is on establishing a method which will enable the organization to better understand the stated benefits expected from executing its IT investments. This focus is a result of evidence suggesting that many business cases either exaggerate the expected benefits or lacked elaboration on the business change required to have them realized (and see also “Bent Flyvbjerg’s Research on Cost Overruns in Transport Infrastructure Projects ” where it could be argued that the affected business cases could have also been ‘inflicted’ with over estimating the expected benefits).

The approach suggested in the paper is based on the following principles:

Different types of benefits are recognized – the focus is not solely on financial benefits 
Measures are identified for all benefits, including subjective or qualitative benefits 
Evidence is sought for the size or magnitude of the benefits included 
A benefit owner is identified for each benefit – to ensure commitment and aid benefit delivery 
Benefits are explicitly linked to both the IT and the business changes that are required to deliver them– this ensures a consideration of how the business case will be realized is also included 
Owners are also identified for the business changes – in order to ensure they are completed and result in benefit delivery.

The paper suggests a multi-step approach to building an adequate business case:

1. Define Business Drivers and Investment objectives

Business Drivers refer to the issues and problems (internal and external) faced by the organization. Investment Objectives refer to what the proposed investment seeks to achieve. Determining and enumerating the Business Drivers provide an answer to the ‘Why’ we want to make this investment, while the articulation of the Investment Objectives provide and elaboration of ‘What’ would the proposed investment seek to resolve.

2. Identify Benefits, Measures and Owners

Having identified the Business Drivers and Investment Objectives “it is then necessary to identify the expected benefits that will arise if the objectives are met. Investment objectives and benefits differ in the following way: investment objectives are the overall goals or aims of the investment, which should be agreed by all relevant stakeholders. In contrast, benefits are advantages provided to specific groups or individuals as a result of meeting the overall objectives. Provided the benefits to  different groups or individuals do not give rise to conflict, there is no need to agree them“.

Identifying the benefits, while important, must be supplemented by two additional activities. The first being a clear articulation of how the expected benefits could be measured and the second being naming the person that will be the owner of the benefit. The owner’s ‘job’ would be to provide a ‘value’ to the benefit and ensure there is a plan to have the benefit realized once the investment has been made.

3. Structure the Benefits

Benefits identified are required to under-go another level of categorization and classification along two specific dimensions:

Benefits - Dimensions

1. Organizational changes enabling Benefits

Benefits can arise as a result of different types of business changes, classified by the authors as:

a. Do New Things – where the “organization, its staff or trading partners can do new things, or do things in new ways, that prior to this investment were not possible“; or

b. Do Things Better – where the “organization can improve the performance of activities it must continue to do“; or

c. Stop Doing Things – where the organization “stop doing things that are no longer needed to operate the business successfully“.

2. Degree of explicitness

The ‘Degree of explicitness’ refers to the degree to which a value assigned to the benefit could be substantiated (perhaps a better name could be ‘the level of substantiation’). The authors identify four level of ‘explicitness’ that could be ascribed to each benefit:

a. Observable benefits – “these are benefits which can only be measured by opinion or judgement. Such benefits are also often described as subjective, intangible or qualitative benefits“.

b. Measurable benefits – “these are defined as benefits where there is already an identified measure for the benefit or where one can be easily put in place“.

c. Quantifiable benefits – these are benefits “where an existing measure is in place or can be put in place relatively easy. However, in addition to being able to measure performance before the investment is made, the size or magnitude of the benefit can also be reliably estimated“.

d. Financial benefits – “these are benefits that can be expressed in financial terms. A benefit should only be placed in this [category] when sufficient evidence is available to show that the stated  value is likely to be achieved“.

It will be easier to understand the way the two dimensions (Organization Changes and Degree of Explicitness) interact with each other by using a number of examples (taken from the paper – see there for the complete list):

Benefits - Observable

Benefits - Measurable

Benefits - Quantifiable

Benefits - Financial

4. Identify Costs and Risks

In addition to the benefits, a full business case must obviously include all the costs and an assessment of the associated risks“.

In Summary…

The authors make the observation that “of all the aspects of business case development that differentiated the successful from the unsuccessful groups, evaluation and review of the benefits was where the differences were most pronounced. It would seem reasonable to suggest that the rigor with which an organization appraises the results of its IT investments will significantly affect the quality of the business cases on which investment decisions are made“.

Some final thoughts

The key message of the reviewed paper is that there is more to the Business Case than just being a vehicle for obtaining funding. Important as it may be, funds allocation is consequential and is secondary to the ability to clearly articulate, understand, manage and realize benefits. The paper allocate very little space to explaining how costs and risks are to be identified, assuming – I guess – that compared to the task of identifying and classifying the benefits, cost identification is relatively easy or, perhaps, not as important (in relative terms) to the task of identifying the benefits. Better understanding benefits would enable management to determine how much they will be willing to invest to realize those benefits.

Think about it!

%d bloggers like this: