Author: Cynthia Low

Change Can Be a Good Thing

Written by Cynthia Low on May 5, 2009. Posted in Articles.

Transitioning from ITIL V2 to V3

Not to long ago, the ITIL community was collectively starting to breathe again after the long wait for the publication of ITIL Version 3. The word before publication had been that V3 was an incremental update to V2, so we were told not to worry too much.

But what an “increment” that turned out to be! While we knew that V3 would be based on a service lifecycle that was a distinct (but welcome) change from ITIL V2, what we didn’t know was the extent of new material in V3. The old tried and true material was still there (appropriately updated), but two completely new aspects were included in V3, namely Service Strategy and Continual Service Improvement.

To back up for a moment, the IT Infrastructure Library, or ITIL, is a best practice framework aimed originally at IT Operations. The emphasis was on ensuring IT services would run as advertised, and any interruptions to service would be quickly resolved, permanent solutions to problems would be found, etc. Version 1 was written at the end of the 1980s, and a consolidation of the numerous books in Version 1 was done around 2000 and became Version 2. There are two main books in Version 2 (Service Support and Service Delivery) and five ancillary books, which most people are unaware of and even less have read. Both versions are derived from real-world experience and have a great deal of wisdom in them.

ITIL Version 2 gained real traction from about 2001 onwards, and now is a de facto standard.

Many people felt there wasn’t much “broken” in Version 2, so while an update to ITIL was welcome, we were not expecting a wholesale change. Consequently, there was a lot of whining about the necessity of the new material in Version 3.

So what has V3 really given us? After living with the five volumes of ITIL Version 3 for the last year or so, I can tell you it has delivered a lot! While we may not have thought ITIL V2 was ‘broken’, I now believe it was. Probably the best example of how ITIL V2 was “broken” concerns the definition of a service.

ITIL implementations based upon V2 usually stalled after implementing the processes in the Service Support book. The Service Delivery book is really about Service Level Agreements and what you need to do to support them.

A huge hole exists in V2, because it never really defines what a service is in the first place. To fill this gap, customers would often have an exercise to write their own definition, which always ended up being convoluted and incomplete. Consequently, efforts to build processes based upon a poor definition ran into problems, and the processes were ineffective.

The Service Strategy volume of ITIL V3 gives a very good definition of a service. While it looks esoteric at first glance, the definition stands up to scrutiny and provides the basis for all the work that follows on (such as the definition of Service Level Agreements). Additionally, the Service Strategy volume addresses the question of which services should be offered. This is where true business alignment (an often used, but poorly understood, expression) begins!

The Continual Service Improvement volume adds an essential element to ITIL in that it shows how to sustain the effort to implement ITIL. In fact, ITIL is more of a journey than a destination, and effort needs to be expended on a continual basis, just like the old-time, quality programs have always told us. While I believe there will be more added to CSI in the future, the current volume provides a starting point for continual improvement efforts.

ITIL Version 2 had three levels of certification, namely Foundation, Practitioner, and Service Manager. For Version 3, the certification scheme is more complicated, but can be summarized as four levels – Foundation, Intermediate, Expert, and Master. So far, V3 Foundation and V2-to-V3 Foundation bridging classes are available, and additionally, a V2-to-V3 Service Manager bridging class is in the market place (the last course has a very limited audience).

The Foundation classes are very popular. They are essentially there to provide an overview of ITIL Version 3, and do a fine job of providing that.

There are two distinct types of courses at the intermediate level – the Capability courses and the Lifecycle courses. Capability courses are aimed at people who are implementing or running the ITIL processes, and they are the replacement for the V2 Practitioner courses. There are four Capability courses each covering several related ITIL processes. Lifecycle courses are aimed more at managing the processes and will not delve into implementation issues as much as the Capability courses. There are five Lifecycle courses, each one covering one of the five volumes of ITIL Version 3 (Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement).

If you are implementing ITIL processes, or if you have already implemented them and want to continually improve them (you should!), then one of these courses is for you.

In addition to the knowledge gained on each course, they set you on a path to get the ITIL Expert and Master designations.

In summary, ITIL Version 3 has added a great deal to our industry and set us on a path to a much fuller integration of IT into the business. ITIL Version 2, when it was published, was a guidepost we followed until we caught up with its advice. ITIL Version 3 continues that tradition with many new ideas that we at first will struggle to implement, but which we need to do for IT to be valuable to the business.

Geoff Senson is an instructor for Global Knowledge with a specialty in all levels of training for ITIL V2 and V3, especially the intermediate and advanced courses. He has over 30 years experience of IT in a variety of environments, including extensive work in large enterprises. Global Knowledge is a worldwide leader in IT and business training. For more information, visit www.globalknowledge.com

ITIL educator for all levels of V2 and V3; implementation experience of ITIL in many high performance environments; over 30 years experience of IT in a variety of environments, including extensive work in large enterprises

Geoff Senson’s Specialties:
All levels of training for ITIL V2 and V3, especially the intermediate and advanced courses. Cobit training.

About the Author
Tom Grzesiak, PMP, is an instructor for Global Knowledge and is the president of Supple Wisdom LLC. Tom has over 20 years of project management and consulting experience with IBM, PricewaterhouseCoopers, and dozens of clients. He has trained thousand of project managers and consultants. Global Knowledge is a worldwide leader in IT and business training. More than 700 courses span foundational and specialized training and certifications. For more information, visit www.globalknowledge.com

Getting Your Self-Assessment Message to the People at the Top

Written by Cynthia Low on April 28, 2009. Posted in Articles.

Communicating upward in any organization can be difficult and stressful for associates who are passionate about their message. This scenario is even more difficult when the associate is trying to communicate his or her own value in conjunction with a growth or financial development plan.

There must be several baseline items considered prior to formulating any communication:

The employee should be aware of his/her standing as it relates to “true” performance. It is imperative to be honest with yourself about how the work you do is being received and aligned with both personal and corporate objectives. Many times a gap between performance and objectives due to varying agendas creates a breakdown between employee and employer.
The employee should elicit unscheduled feedback during the review cycle to ensure that his/her performance is staying the course. This also allows for a re-alignment of behavior and objectives as the corporate needs and/or culture may shift.
The employee should perform a goal/value analysis of his/her standing within the organization. This is accomplished by aligning your beliefs, goals and values with the organization you work for. It is imperative that the employee be sure they are not forcing the continued relationship. This is one of the most important factors in the effort to ensure job satisfaction and ultimately one of the most overlooked. Getting yourself into a rut is the most common mistake when evaluating self-worth and ultimate career goals. Change is hard, but sometimes it must be made.
The employee should have a plan that illustrates their objectives, and, most importantly, structure this in a collaborative way to ensure it is not received as an “agenda.”

Once the employee completes the development of a baseline communication plan as noted above, the following items should be crafted into the delivery format:

The employee would be well served to draft a brief for the communication. This is not suggesting an agenda, but something less formal to incorporate a value statement, self-assessment, recent accomplishments, past performance analysis and desired path forward. The brief can be used as a guide during the presentation and may or may not be handed out. Most importantly this exercise helps the employee to formulate and format an organized presentation.
The employee should have considered a coaching/mentoring plan to support their desired development and present it in a low key yet confident way. This action will expose his/her willingness to learn and dedication to continued development.

The employee should consider what financial expectations are associated with the next step in their career and know how these expectations align with the organization’s structure. In small organizations requests for profit sharing and limited vesting are not uncommon but need to be considered carefully as the “owners” are far more protective than a “supervisor.” In these cases, present tenure, contribution and continued value-add as the long-term benefit. It would also be helpful to illustrate historical growth and commitment to support a more intimate relationship with the organization.

When the items above are complete all of the pieces are now ready to deliver a well-planned communication to your boss. Here are some delivery notes that will be helpful when making the presentation:

Always open with a quiet yet confident statement about why you have called the session. It is important that your confidence be very visible but not taken as over aggressive.
When aligning your plan with that of the organization, try to leverage real life examples of how the efforts you have contributed showed value above expectation. Additionally, you want to look forward to how this path will create continued value and growth.
Never brush against the essence of “entitlement.” Remember that the organization does not “owe” you anything. This is very important especially when requesting further vesting and/or initial vesting in small organizations.
Take the time to understand your boss and his/her expectations, goals and relationship with you. It is always helpful to prepare by role-playing with a “non” co-worker to establish a smooth delivery.
Never share your plan or thoughts with anyone else in the organization.
Plan a neutral location for the meeting, off site always works best to level the field and avoid distractions.
Don’t represent a position of “negotiation.” You are not there to win/lose, you are there to identify value add points for your own position and the organization. The best-case scenario will play out naturally if you guide the process with integrity.

Once this process is complete, repeat the goal/value analysis. Unfortunately, one of the worst positions you can be in is one of weakness once the results are rendered. In other words, be willing to make changes against to your personal career plans if you are not comfortable with the results of the effort.

Time is your most valuable commodity.

Phil Ventresca is Founder, CEO and President of Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. Since founding AMS nearly two decades ago Phil has lead the organization to becoming an internationally recognized provider of Consulting, Training and Assessment services. AMS’s client base is comprised of Fortune 100/500 companies, medium-sized businesses and Government agencies that Phil has personally assisted in the creation of organizational and performance based solutions. Phil has designed business methodologies, processes and personnel performance plans for organizations such as, AT&T, Fidelity, The Hartford and many more. Phil maintains an active role providing executive coaching and account solution development for the AMS family of clients. As an entrepreneur Phil has founded AMS Aviation and PTV Equity both wholly owned subsidiaries of AMS.

Requirements Definition for Outsourced Teams

Written by Cynthia Low on April 28, 2009. Posted in Articles.

In today’s economic environment, business organizations are demanding focused attention to fiscal discipline. IT organizations are finding themselves asked to support in-production applications on flat budgets, and new development is largely being approved only by the rule of efficiencies. Software applications are the focal point of improving efficiencies, as consolidation and integration projects can both reduce support costs of multiple siloed applications and streamline business processes for end users.

In this effort to do more with less, IT software groups are turning to outsourcing in record numbers in 2009. According to IT World, the economic collapse of 2009 has accelerated the use of outsourcers for software projects to record levels 1.

With CIOs turning to outsourcing as a strategic imperative to increase efficiencies for software projects, new challenges are being introduced that threaten the same efficiencies CIOs are moving to achieve.

By definition, outsourcing introduces third-party goods and services to augment capacity and capabilities. Since IT software has mission-critical implications, such third-party influence places a new burden on the business to ensure that these outsourced teams are properly goal-oriented, properly instructed, and properly managed to ensure productivity.

While there are many areas that can be influenced to ensure outsourcer success, there has been study after study that indicate the true control point for IT software projects is application requirements definition.

What follows explores industry, analyst, and customer recommendations on how to focus on requirements to ensure application development accuracy and to control risks so that the IT organization can turn those efficiencies into increased horse-power and lower operational costs.

Requirements Communication: A Challenge for IT Project Teams

The quality of requirements communication is a significant challenge for IT project teams, whether they are co-located or distributed. In the Software Development Lifecycle, the time dedicated to requirements definition has largely been consumed at

the early stage of the lifecycle, and it has involved dozens of subject matter experts who typically carry the title of business analysts or business systems analysts.

However, recent studies indicate that while business analysts do consume up to 10% of the project budget documenting requirements specifications 2, the result of their effort is typically in the form of difficult-to-understand paper-based documents. These paper-based documents are largely consumed by IT project teams, who must work to understand the intent of the author and translate the business need into detailed specification documentation.

Even in IT projects which largely consist of in-house development teams, i.e. not outsourced, the resulting rework and waste has been measurable. IAG tells us that typical waste and rework levels of poor requirements trace directly to upwards of 40% of budget consumption 3.

As IT organizations move to embrace outsourced teams as an extension of IT software project teams, the challenge of communicating requirements is exacerbated. MetaGroup tells us that over 50% of organizations that leverage outsourced teams have critical business-application knowledge in the minds of in-house developers that have been disenfranchised by the outsourced labor pool 4. As a result of this loss of subject matter expertise, outsourced IT organizations increase their dependence on the customer to

produce highly precise and specific requirements documentation. MetaGroup also tells us that turnover rates in outsourced service providers run at an average of 15-20%, resulting in a likely chance that specific talent assigned to your project will experience turn-over during the project cycle. This continues to reinforce the need for easily referenceable and consumable requirements direction. Experienced outsourcing customers and industry analysts have identified the appropriate focus areas to ensure IT project teams’ success when deploying outsourcing. While there are many areas that can impact the success of an IT team that has moved to leverage outsourced teams, there are a select few that dramatically improve success. IDC’s recent report on control points to outsourcing success helped draw focus to the most important areas.

IDC continues to articulate the control points that ensuring outsourcing is an opportunity for efficiency and not a threat to efficiency involve the strategic touch-points to the outsourced team. IDC documents these touch-points to be requirements definition, quality assurance, and in-flight project collaboration 5 Other analysts such as Gartner, voke, and Forrester all have offered supporting research, which point to these same control points.

Controlling the Control Points

As mentioned earlier, there is a generally accepted principal of the importance of requirements, quality assurance, and collaboration when aligning outsourced teams. However, when IT arranges the control points in relation to one another, the logical focus priority of requirements is revealed. As you can see in Figure A, the quality assurance and project collaboration control points are directly impacted by the depth, quality, and understanding of the project Requirements Definition phase. In fact, rarely is a single quality assurance test scenario not directly based on (and traced back to) functional or non-functional requirements. A modern quality assurance trend is a move toward test-based-development, a trend that is accelerating with outsourced teams. Test-based-development builds a one-for-one relationship between test cases and requirements, where literally a test case can function as a requirement asset. In addition, collaboration with development is often directly linked to the implementation of a business requirement, or how the software influences that requirement.

Figure A: Relationship with Requirements to QA and Collaboration

By directing focus on improving requirements definition, IT project teams that leverage outsourcing groups can better manage all control points, and thus improve the impact and focus of quality assurance and inflight collaboration efforts.

Problems with Requirements Communication

As we discussed in the previous section, working with outsourcers bring obvious challenges of aligning distributed, third-party resources around project goals. Location challenges alone can introduce time zone and collaboration barriers that can tax productivity and efficiencies. However, with third-party organizations, IT groups can introduce additional challenges that include processes, tools, training, context, domain expertise, and incentives.

Requirements communication fits squarely into the center of this challenge. As we discussed, traditional methods of communicating requirements, which include enumerated lists of features, functional and non-functional requirements, business process diagrams, data-rules, etc., generally are documented in large word-processing or spreadsheet documents. When applied to an outsourced team, this method of communicating creates significant waste and opportunities for failure, as the barrier to understanding is too large to overcome.

Incorrect interpretation and the lack of requirements validation can create artificial (or false) goals which consume valuable outsourcing resources. Due to the nature of software development, these false goals usually manifest themselves into incorrectly implemented code, resulting in costly waste and rework. Outsource providers often treat such rework as “changes”, and bill back these “changes” to the customer. This continues to erode the efficiency that IT organizations strive to achieve when adopting outsourcing in the first place.

Models, Validation and the Requirements Contract

To significantly reduce the probability of ineffective requirements communication through natural language documentation, IT organizations are transitioning to more precise vehicles to communicate requirements.

One of these vehicles is the adoption of the model-based approach to communicate requirements in a highly visual way. Requirements models provide detailed context capture through highly precise data structures. Complete models include the use of universally accepted formats as structural guides, interlinked them together to create a holistic representation of the future system. The formats used in these holistic representations include use-cases for role (or actor) based flows, user-interface screen mockups, data lists, and the linkage of decision-points to business process definitions. These structures augment enumerated lists of functional and nonfunctional requirements.

The benefits of models include the use of simulation to ensure requirements understanding. Simulation is a communication mechanism that walks requirements stakeholders through process, data, and UI flows in linear order to represent how the system should function. Stakeholders have the ability to witness the functionality in rich detail, consuming the information in a structured way that eliminates miscommunication entirely.Models and simulation also provide context for validation. Validation is the process in which stakeholders review each and every requirement in the appropriate sequence, make appropriate comments, and then sign-off to ensure the requirements are accurate, clear, understood, and are feasible to be implemented. Requirements validation can be considered one of the most cost-effective quality control cycles that can be implemented for an outsourcing initiative.

Since requirements are the “blueprint” of the system, outsourced stakeholders can make use of requirements models and simulation during implementation to gain understanding of the goals of the project. Simulation eliminates ambiguity by providing visual representation of goals which in turn eliminates interpretation.

Rich requirements documentation often is a specified deliverable for most IT projects for various reasons that include regulatory compliance (Sarbanes Oxley, HIPAA, etc.), internal procedural specifications, and other internal review cycles.

This documentation also serves as the contract between the customer and outsourced provider. Models can serve as the basis of this documentation and next generation requirements workbench solutions (such as Blueprint Requirements Center) can transform models into rich, custom Microsoft Word documentation. Since these documents are auto-generated, the amount of effort required to build and maintain these documents is minimal

Abstract vs. Detailed: Outsourcer Involvement in Requirements Definition

Outsourcing providers have learned a tremendous amount about how to improve the efficiencies of requirements communication. Many providers are shifting to a much heavier involvement in the process of Requirements Definition. Others continue to operate in a more traditional model, which abstracts them from the requirements definition process, leaving this on the shoulders of the customer.

Western outsourcers have heavily pioneered and practiced an approach that includes efforts to work with customers to articulate, document, and communicate requirements. Part of the value proposition of this approach is that the outsourced provider mitigates the risk of misunderstanding, and ensures that members of the outsourced team gain a clearer understanding of the project goals and deliverables. This approach is often referred to as a detailed approach for requirements definition in outsourced projects.

Indian and European outsourcers largely continue a practice which abstracts outsourced providers from the definition of requirements. Such abstraction means that the customer takes on responsibility to clearly document and articulate requirements to outsourced providers. This requires that the customer partake in extremely accurate and precise specification of project requirements, knowing that cultural, time zone, process, and alignment barriers that exist in the interpretation of these requirements. This approach is often referred to as an abstract approach for requirements definition in outsourced projects.

It is important for an IT organization to understand which of these two approaches are taken, as they can dramatically change the methodologies and practices required to ensure clear understanding of project requirements.

The Solution: A Case Study

The principles described in this paper should be considered and applied at the earliest stages of the project both to set the stage for the work that follows but also because the earlier errors are discovered and resolved, the less expensive the impacts of those errors will be. Just as the cost of errors increases exponentially the later they’re found in the lifecycle, the corollary is also true – to find and deal with them early can result in exponential savings. In the case of outsourced development this should happen even before the outsourced vendor is chosen, during development of the Request for Proposal (RFP).

An example of such a case is provided by Knowsys, a Blueprint partner. Knowsys staff were contracted to come in late to an RFP cycle that had gone awry at a major North American financial institution. This company needed to re-architect their entire e-commerce platform for their Wealth Management business. Significant investment had already been made in the RFP process and when Knowsys arrived, the client was just beginning a series of vendor presentations with senior executives of the client in attendance, summarizing their bid for the outsourcing contract. As the presentations continued, the “elephant in the room” kept getting bigger and bigger. It had become clear that something had gone terribly wrong.

The requirements specified in the RFP to the vendors were incomplete. There was conflicting information and inconsistent levels of detail. Upon further analysis, it was discovered that whole business areas were neglected. Compounding this was the fact that subject matter experts had incorrectly assumed how certain areas of the business functioned. These inaccuracies were further compounded by the various vendors who bid (seven in all) by layering on their own assumptions to fill in the gaps. The result was a series of vendor presentations that were wildly different, almost as if they were trying to address seven different problems and none of them being that of the customer. In addition to uncovering these major flaws in the requirements of the RFP, this event also made obvious that the process for inviting vendors was less than perfect. Some had clearly invested huge amounts of time and effort in the proposal, while others less so. None had sufficient familiarity with the customer’s business or situation to be able to point out obvious flaws.

In effect, the reset button was hit. The executives directed the group, with Knowsys now involved, to redevelop the RFP. This time executive sponsorship was front and center and all aspects of the business were directed to be accessible and support the initiative. All relevant aspects of the business were thoroughly analyzed and their needs amalgamated into a unified representation of the requirements. Validation was performed to ensure coverage, depth, and clarity. Much more rigor was applied to the process of vendor selection for bidding (a contrast from the open invitation used in the first cycle). A smaller group of more focused vendors who knew the client’s business were invited. The Knowsys team also made sure the vendor relationship was far more collaborative, while respecting the impartiality required of bidding process. Theyensured there were multiple points of client-vendor contact and also put measures in place to ensure that any and all assumptions were validated. Finally, an emphasis was also applied to quality assurance and testing aspects (as opposed to a sole focus on the requirements of what was to be built) to produce a much more rounded picture of the bidder’s proposals.

The net result of these initiatives was tremendous. The second set of presentations, by a much smaller group of bidders, was like night and day compared to the previous round. It was clear that each vendor had a very accurate grasp of the client’s problem and goals. Each proposal was compelling and had unique and interesting variations on their proposed solutions.

A vendor was selected and the project got underway, later than hoped due to the failed initial RFP cycle. Everyone felt much more confident entering such an important development initiative with the specifications they now had, the vendor they had selected, and the proposed solution. That confidence was validated when the project, even in the face of unexpected business changes during the project, was delivered on time and on budget with all success criteria being met. Had this financial institution selected a vendor in the first round, and proceeded with development on that basis, the results would undoubtedly have been quite different.

Conclusion

The steady rise in outsourcing of software development has increased in the recent economic climate as companies desperately seek ways to reduce IT costs. The promise of cost savings is realizable, but only to those who focus on three vital requirements control points in the outsourcing arrangement: requirements communication, requirements reference, and requirements validation. Gaining mastery of these through

appropriate processes, practices, and automation will dramatically improve the probability of success of the outsourced engagement, delivering the needed cost savings.

Footnotes

[1] Five trends that challenge technology offshoring in 2009, IT World
[2] Thorny Requirements Issues Handbook 2005 – Process Impact – Karl. E. Weigers.
[3] IAG Requirements Survey, 2007
[4] MetaGroup, Search CIO Top 10 Risks of Offshore World
[5] IDC Analyst, Melinda Ballou, Offshore your Way to ALM, RedmondMag

Matthew Morgan is a 15 year marketing and product professional with a rich legacy of successfully driving multi-million dollar marketing, product, and geographic business expansion efforts. He currently holds the executive position of SVP, Chief Marketing Officer for Blueprint, the global leader in Requirements Lifecycle Acceleration solutions. In this role, he is responsible for strategic marketing, partner relationships, and product management. His past tenure includes almost a decade at Mercury Interactive (which was acquired for $4.5B by HP Software), where he was the Director of Product Marketing for a $740 Million product category including Mercury’s Quality Management and Performance Management products. He holds a Bachelor of Science degree in Computer Science from the University of South Alabama. He holds a Bachelor of Science degree in Computer Science from the University of South Alabama.

Building the Business Case

Written by Cynthia Low on April 21, 2009. Posted in Articles.

What Is a Business Case?

Business cases are arguments for or against making a specific decision based on economic considerations. They are tools for decision-making. A business case describes the economic consequences of a business decision and makes a recommendation.

An Issue of Economics

Business cases are focused on financial issues. The term “case” refers to an argument. The term business implies that the considerations are economic rather than something like legal or moral. The arguments for or against a decision revolve around cash flow projections. These projections model (forecast) the financial results associated with a recommended action or investment.

In order to be convincing, the assumptions, rationale, and data used to make the cash flow projections (forecasts) must be fully explained and be believable by the target audience. Economic impact is measured using financial metrics. The metrics that are used differ between business cases. The core consideration is discounted cash flows which are used to determine payback period, net present value, and internal rate of return.

Building a Case

One can think of business cases as being similar to court cases. The objective is to present information so as to create a convincing and compelling case for the recommendation that follows. Like lawyers presenting a case in a courtroom, authors of business cases have tremendous flexibility in how information is presented. As with legal cases, business cases must tell a story that demonstrates clear logic, supported by facts, evidence, and sound reasoning.

Ingredients of a Business Case

Well-crafted business cases have a number of essential ingredients. Authors have flexibility in how these ingredients are presented, but must ensure that each broad category of information listed below is included. The more effectively each of these subject is addressed, the better the business case.

Title page
Forecasts
Methods
Executive summary
Conclusions
Assumptions
Introduction
Recommendations
Sensitivity analysis
Disclaimer
Reasoning
Risk analysis
Metrics used
Actions and next steps
Appendices

Title Page

The title must be descriptive. It should identify the nature of the analysis and the decision under consideration. Subtitles are meant to add clarity to the main title. They explain the context of the decision in terms of dates, data, or other considerations. The title page must include the authors, their qualifications and the distribution list. Be as specific as possible. Include titles and names of committees and chairpersons, or even members of the committee. Anyone picking up a business case should understand who the intended audience is.

A business case should never be anonymous. Receiving an anonymous business case would be like receiving an anonymous stock tip: there is no way to judge its validity. The credibility of a business case is completely dependent on the credibility of the author.

Dates

A lot of time-related information is included in a business case. Data goes stale. In order for the audience to understand the relevance of a business case, it must include:

The date of original completion (when analysis ended)
The latest revision date

Within the document, be sure to include reference dates on data used in the analysis. Sales patterns that are five years out of date may not be considered relevant to the reader, even though the author chose to include them.

Executive Summary

The executive summary is what most people read first and is the only thing that many people will read. The executive summary tells readers whether the information in the report is worth their time. It deserves careful crafting.

The executive summary gives the essence of a business case in a few terse sentences. It serves as a proposition (recommendation to act) that is supported, or justified, by the contents of the business case.

The executive summary is a summary of the report. It tells the reader the document’s purpose: what will be proposed, what information is presented, and what action is expected from the reader. And all this is, of course, from the perspective of the author. The executive summary should include both a verbal description and numerical information summarizing high level metrics (return on investment statistics) that support the recommendation. Although an executive summary appears first, you always write it last, after you know which recommendation the analysis supports.

Introduction

Business cases must begin by being put in context. It is necessary to explicitly describe what the case is about and why it is being undertaken.

The introduction must include a reference to the subject and purpose of the business case, as well as a brief background. After reading the introduction, the audience should understand the scope and objectives behind the decision under discussion. The subject or purpose of a business case must be presented in terms of business objectives, that is, with reference to business outcomes that follow from the decision being proposed.

Disclaimer

Disclaimers are a little bit like confessions. The longer you delay them, the less valuable they are. If a business case is being presented to an audience outside your company, then a disclaimer of some kind is a good idea. Use wording recommended by a lawyer. Include the disclaimer near the beginning of the business case, on its own page. Do not hide it.

Metrics Used

Explain early in the presentation which metrics will be used to judge results, and why. If, for example, the deciding organization’s hurdle rate for investment is an internal rate of return of 25 percent or a 3-year payback period, it is important to state this at the outset. Let the readers know why the analysis is focused toward these metrics.

Forecasts

The executive summary warns the reader of what to expect. The forecasts section outlines the principal data used to come to the recommendation given. This is where many readers start their reading; it is where the justification for a recommendation is revealed.

Cash Flow Analysis

The heart of a business case is the cash flow analysis. This analysis models the projected inflows and outflows of benefits, which are quantified in terms of dollar values.

Cash flow projections are created for each scenario under discussion. It is not necessary to include reams of data. Include a chart only for the most likely scenarios; include only the summary statistics for the remainder of your analysis.

When preparing a cash flow analysis, it is necessary to provide a reference point. The “business as usual” or “no decision” scenario is used as a base case. Cash flows in other scenarios are then compared to the base case.

Financial Metrics

Cash flow analyses lead to a series of net cash flows. These net cash flows are then used to determine a variety of metrics that relate to performance. It is through these measures that it is possible for readers to judge the merits of each scenario relative to standards established by the company, or to the results of other investment decisions being considered.

Non-Financial Results

Business cases are all about numbers. Any benefits that cannot be quantified in dollar terms are likely to be ignored or undervalued. It is best to assign a valuation to “soft benefits.” When that is not possible, these benefits must be included by way of descriptions. The descriptions should be in the context of tangible, business-related impacts that can be reasonably expected to occur. Non-financial benefits should be discussed at length in a section labeled as such and should be referred to in the executive summary and conclusions so as not to be overlooked.

Conclusions and Recommendations

A conclusions section is included when you are reporting on findings, but no specific follow-up action is required. Recommendations are presented when the reader is being asked to agree to or approve some form of action.

After reading the conclusions, the reader should understand your interpretation of the data and the significance of the results. After reading the recommendations, the reader should understand the plan of action proposed, why it is proposed, the benefits, and the specific actions required of the reader.

Make the recommendations as clear and concise as possible. You are asking the reader to do something; make sure there is no ambiguity about what the request involves.

In complex reports, it may be appropriate to have separate sections for conclusions and recommendations.

Reasoning

The reasoning section immediately follows the recommendations and provides justifications for the recommendations. This is the section that explains the logic behind your recommendations or conclusions. It details the separation between facts and reasonable assumptions. It might also be referred to as “rationale” or “key findings.”

The reasoning section is the persuasive part of a report. It explains in simple terms why the author is right. There should be three to five key points. More than five key points is too many, and fewer than three suggests a degree of uncertainty on your part. Each point needs to be a narrowly focused aspect of your rationale, and it should comprise a sentence or two.

Organize your points in descending order, with the most significant first. Do not smother your message in numbers. Simple graphics (charts and tables) are helpful, but complexity is not. Summarize everything and put the data and complex information in appendices that the reader can refer to if desired. All material appended to a report should be referred to, at least once, within the document. If information has not been referred to, it is not needed to support the body of the report and can be eliminated.

Actions and Next Steps

In the action section, steps are outlined that will be followed if the plan or recommendation in the report is approved. The reader has been asked to agree to some activity, and this section explains exactly what the immediate response will be. Action sections are typically written in point form, in order of sequence. Each activity, or step to be taken, is described in terms of timing, people, and method.

Data and Approach

Readers must know how data was developed. If data has been extracted from another source, this must be explained. When data has been generated by assumptions, explain how and why. Be especially clear in describing the methods used to assign values to soft benefits. Let the reader know your reasoning.

Additional Information

Sometimes you just need to include more information or explanations than can be included in the body of the report. The “additional information” section is the place to include this extra information. The beauty of the additional information section is that it allows the author to include less detail in earlier sections of a report. If a recommendation does not make sense, and the reasoning section does not adequately

explain it, then the additional information section will. It is all part of the pyramid of information – the most important and briefest at the top with more and more detail as you move toward the bottom of the pyramid.

Scope

The boundaries of analysis should be clearly stated. If the analysis considers data from only one operation, or one segment of a complex organization, this needs to be explained. There are always limits to the data included in an analysis. Explain what the boundaries are. What information was included, what was not, and why?

Assumptions

With business cases, numbers (metrics) tell the story. How the numbers were derived is critical to the credibility and persuasiveness of the case presented. In the assumptions and approach section, readers are given an unambiguous explanation of the background of the numbers. When making predictions on such things as sales patterns and expense streams, it is best to follow accepted practice. If other business cases have been approved by the same decision-makers, then use the same type of assumption when making your cash flow projections. Simplifications are almost always necessary. Make them logical and their implications apparent.

Soft Benefits

Business cases are all about numbers. However, in many situations the benefits of a decision are not limited to easily-measured financial gains. In the case of soft benefits, it is necessary to assign values to the soft benefits and include a detailed explanation of the methods and reasoning employed.

Valuation of intangibles is difficult at the best of times. Before including intangible valuations in a business case, get agreement with the readers. Find out from the audience what they consider to be an acceptable method for assigning values. Doing this first can save a lot of time.

Sensitivity Analysis

Business case scenarios are financial stories. They are like a movie that has a number of different endings. The business case creates a financial model that tells a story (illustrated by a cash flow forecast). Scenarios are different endings (outcomes). Each scenario represents a particular set of assumptions and provides a prediction of the impact of those assumptions. The tendency of authors is to include too many scenarios. Readers are much less familiar with the subject matter than the author and cannot digest more than three or four variations. Choose the most illustrative.

A common mistake made in business cases is to omit the “business as usual” scenario.

This is the baseline case that serves as a reference for doing nothing. It is an important part of putting the implications of various decisions into perspective.

Risk Analysis

Risk analysis is all about “what if.” Projections are used to predict the financial implications of various decisions based on assumptions of what the outcomes will be. What if those assumptions are not correct? What is the worst case scenario? What is the best-case scenario? How likely are the projections to be correct?

Within a business case, only a few separate scenarios can be discussed. However, in deciding which to present the author will have studied dozens of scenarios as part of the process of sensitivity analysis. In sensitivity analysis, variables are adjusted up and down to simulate the effect of changes in assumptions for such things as sales and costs of goods sold. The effect of adjusting one variable at a time is related to financial

results. Through these simulations, the analyst is able to determine what the major factors are in relation to the financial results. For instance, the cost of capital goods might increase by 100 percent from predicted and have only a one-percent effect on the rate of return. However, a five-percent increase in labor costs might have a 20-percent effect on the rate of return. Clearly, labor costs are a major factor, while capital goods are not. All the major factors deserve special attention. The discussion of risk centers on an analysis of how robust the predictions are for those major factors that have the greatest potential to affect overall success.

Risk Discussion

Every proposal carries risk. A business document is not complete without a discussion of uncertainties. The obvious risks do not need to be addressed, such as the loss of the whole investment, should the entire plan fail. Instead, include only a limited number of significant risks. Include those that may have a significant impact, have a high degree of probability, or are unusual and may not be immediately obvious to the reader. When describing the risks, it is important to explain how the risk has been quantified (given a sense of magnitude) and what measures are possible to eliminate the risk.

Significant risks should be discussed in terms of their impact on the project. What is the worst-case scenario if the risk comes to fruition? What is the worst that might happen?

The worst-case scenario is the downside. It is considered unlikely that these events will occur, but not inconceivable. They are presumed to have less than a 10 percent chance of occurring. The best case scenario is the upside. This is the best that can be hoped for. It is presumed to have a 10 percent chance of occurring: unlikely, but possible. The most likely event is the reference point that the author uses in general discussion. It is the best forecast that the author can offer about what will occur. The most likely scenario is presumed to have a 50 percent probability of occurring.

Appendices

Supporting data and analyses that have led to the recommendation or conclusion are made available through appendices. Do not include materials just to make a report look more significant. Only information that has been referred to within the main report should be included in the appendices. Each type of datum should be separated and labeled within the appendices. Think of sections in the appendices as chapters of background information. Arrange them in a comprehensive order that relates to the body of the report.

Presentation Style

Reports are written in terse business style. Reports should use short sentences, small words, and tiny paragraphs. Many authors get bogged down writing reports because they try to link sections and paragraphs with descriptive prose. Do not bother. It is perfectly acceptable to use point form anywhere and everywhere. Business reports are not poems.

Another common mistake made by authors of reports is to write one featureless paragraph after another. No one likes to read page after page of black text. Mix it up.

Every page should have at least three headings. Use bulleted lists instead of paragraphs to make the material more visually interesting. Be consistent with heading styles. Make sure that the same pattern is maintained throughout the document.

Writing Style

Be realistic, but sound optimistic. An upbeat report is much more pleasant to read than a deadpan treatise. Use the active voice. It reads better. (A passive voice version of the previous paragraph is: An active voice is the preferred style. Many people prefer to read it). Try to be gender-neutral. Do not assume that the audience is male, female, or indifferent to issues of sexual nuance.

As a matter of practicality, be sure to number pages and to include the title and author’s name on every page by way of headers or footers. If the report is dropped, or taken apart by the reader, make sure it can easily be put back together.

What Goes Wrong?

There are two ways that business cases can go wrong. One is for them not to be funded.

The other is for a case to be funded when it should not have been. Both are bad news.

The key to quality is practice. Companies with a long history of preparing and appraising investment proposals have a far better track record than novice investors.

Experience provides standards of accepted practices. It is not that these practices necessarily represent the ideal approach to preparing business cases, but rather that they allow separate cases to be judged against each other. Standards allow an organization to gain experience. Without standards, each business case is an experiment in creative writing. With standards, business cases can

be compared side by side. A problem that caused the failure of one investment can then be used to highlight potential problems in another proposed investment.

Experience teaches investors to be wary of certain kinds of assumptions. Standards in the analysis of business cases allow the implications of those assumptions to be highlighted.

Conclusion

To be effective, business cases must meet the decision-making needs of the audience for which they are intended. There are common ingredients in all business cases; however, the weight and emphasis of the various components depends on the target audience and their particular preferences.

If you do not know what the target audience wants or needs to make a decision, then ask them. Guessing can waste a lot of time. State your arguments in the context of metrics and considerations that the audience considers important. The core of all business cases is net cash flows and the statistics related to them.

Emphasize Economics.

You may feel that network dependability is a critical consideration but the audience may be concerned only about market share. If you cannot explain your concerns in relationship to what the decision-makers consider important (such as how network dependability affects market share), your business case will not be approved.

Remember that a business case is an argument based on economics. Plan what argument you are going to make and then support it with data.

Write in a Pyramid

Business writing does not follow the rules of literary writing. Do not save anything for the end. Write in a pyramid with the most important information (concisely presented) first. After that comes all the supporting details in descending order and increasing volume.

A well-written business case makes the best use of the reader’s time by providing targeted information and by making that information easy to find. Good luck!

Brian Egan is the President and owner of a giftware manufacturing company. The Book Box Company Inc is the world’s largest manufacturer of hollow-book gift products.

Brian has graduate degrees in Oceanography (MSc) and Finance (MBA) as well as PMP certification. In addition to professional development training, Brian provides project management services to companies wanting to improve their performance by incorporating the best of management science methodologies into their operations.

Brian lives with his wife and four children in rural British Columbia. Global Knowledge is the worldwide leader in IT and business training. More than 700 courses span foundational and specialized training and certifications. For more information, visit www.globalknowledge.com

Glossary

Disclaimer: An explanation about the limitations to information contained in a document; a warning that a business case involves an unpredictable forecast of future outcomes

Financial metrics: Performance measure used to determine the costs and benefits of an investment option

Non-financial results: Also known as soft benefits; benefits gained from an investment that cannot be put into strictly financial terms, such as employee satisfaction

Assumptions: Simplifications used to help predict future outcomes of a business investment; include such statements as “labor rates will remain effectively unchanged throughout the forecast period”

Risk analysis: A review of what might prevent the predicted outcome for an investment from coming true

The Lost Art of Business Technology

Written by Cynthia Low on April 21, 2009. Posted in Articles. 1 Comment on The Lost Art of Business Technology

The importance of technology architecture, that is the relationship which exists between hardware and software used to produce the end result desired, continues to elude the 21^st century company. This is unfortunate, as it is a fact that the proper implementation of technology architecture can help business skate over the new and extremely challenging dynamics, such as cost cutting, global demand, and the fierce competition we all face.

Unfortunately, somewhere along the way, architecture has been, for the most part, completely overlooked, underappreciated or even entirely misunderstood by those companies most in need of the discipline which results from its implementation. Furthermore, because of their lack of understanding of its merits and purpose, some companies actually overspend on technology architecture rather than spend wisely.

From the perspective of a skilled craftsman in architecture, the typical ‘troubled company’ is one which states upfront that, for example, it is considering ‘virtualization,’ with its resultant need for an infrastructure plan.

Before adding new infrastructure to achieve its goal, however, a company should ask itself: have we taken all of the necessary steps to ensure we implement the new infrastructure in a way to minimize the need for new software? Can we collapse systems we no longer need for prime-time operations?

This is where the value of technology architecture comes in, but unfortunately has not been embraced by the technology sector.

Of course, in some cases, the problem lies in the fact that some of those who call themselves architects are very vendor specific, and we can argue that they are not architects at all. A core value of being an architect lies in being ‘agnostic,’ that is, embracing any vendor and product set as long as it matches the needs of the business. The last thing we need is three different databases and three database administrators, each trained specifically in a particular vendor’s product. And, let’s not forget that the aim is to actually deliver on tangible, measurable, and realistic metrics, and not just wishy-washy ROI.

My experience is that companies will often spend capital and operational budgets to solve each problem individually, with the result that, before long, the infrastructure is three times what is required.

The benefits of technology architecture are wide reaching, and measurable. For example, the utilization of an architecture roadmap keeps businesses better informed on IT progress, or at least its goals and priorities. As well, risk identification and aversion and the ability to become agile when a critical business need erupts are very much the goal of architecture.

Architecture achieves its goal by linking definitive information in an accurate and timely fashion. Now, when you define a business problem and approach outside vendors for the solution, you will have dramatically reduced costs, even eliminated them outright, because you made the effort to inventory, document and control your infrastructure. Again, when you want to integrate a number of disparate systems, your roadmap will radically lessen the time it takes for implementation.

It is time for businesses to take a more serious look at technology architecture. CIOs and CFOs should seriously consider empowering technology architects with the authority to match their responsibility and lay out the expectations and guidelines they require to measure the benefits expected.

There is an impression, however, held by many in business, that architects are Ivory-Tower dwellers, dictating technical direction. It is important that architects acquire business acumen, and respect the demands, challenges, and budgetary constraints of the business. Architects must be on-side and in tune to each development within the business, whether marketing, sales, products/services, or other areas. Finally, they must remain ‘agnostic’ for the sake of both the profession and the business they represent

Long gone are the days of technology being about the sizzle . . . it’s now all about the steak! Long gone are the days where we implemented a technology for the sake of the spin. Businesses now demand solutions linked directly and accurately to their true problems. They also expect them to work as advertised, on budget and as planned. It is technology architecture that will ensure businesses no longer spend for the sake of spending.

Roger Glasel is a technical and executive architect with Syscom Consulting (www.syscom-consulting.com), Telus Communications in Vancouver, British Columbia.