The Business Case Document

I’m trying to get on a roll providing our readers with some hopefully meaningful samples and templates of documents that may be needed on their projects.  These are templates that I created a few years ago – basically from information I think I probably found somewhere else…(isn’t that always the case?).

As I stated in The Project Charter Document article, if our readers have samples or templates they’d like to share, I’ll be more than happy to provide alternate versions of documents that I’m including here or examples of documents that I’m not covering…either will be much appreciated.  And I’m also very willing to send along Word doc versions of these templates to anyone who asks…just email me.

Here I am presenting a template for a Business Case Document.  If your customer is external, you may never see this or may never be involved with it.  If your customer is internal, it’s very possible that you’ll not only see it, you’ll be asked to help create it.  The key is to try to justify the existence of the project and the work to be performed.  The best way to do that is to show some cost/benefit analysis or return on investment (ROI).

This doesn’t have to be an extremely detailed document – leave that for the statement of work (SOW) and, of course, for requirements documents.  It does, however, need to speak very well to executive management and the key decision makers if there is to be any hope of kicking the project off.  Someone, somewhere, makes the final decision on whether or not to throw $$ and personnel resources at this effort and this document needs to convince them to approve that effort.

PROJECT BUSINESS CASE

[Save file name as: client name BUSINESS CASE yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

SOLUTION

Describe the proposed solution.

COST MODEL

ROI SUMMARY

Describe when the break-even point of the project will occur and expected annual revenue generated by the project.

PROJECT RISKS

Describe risks that may impact the cost/benefit of the project performance.

The IT Auditor’s Role in the Software Development Process

In further examining the IT Auditor’s role in the IT project environment, I’d like to look at how the book “Information Technology Control and Audit” discusses the IT Auditor’s role in the overall software development process.

Software Development Process

A formal systems development process provides an environment that is conducive to successful systems development. This includes: (1) an information systems strategy that guides developers in building systems that are consistent with the organization’s technical and operational goals, (2) standards that guide in the selection of hardware, software, and developing new systems, (3) policies and procedures that support the organization’s goals and objectives, and (4) project management that ensures projects are completed on time and within budget. Auditors can assist organizations by reviewing the systems development process to ensure that developed systems comply with the organization’s strategy and standards.

Software Development Phases

The systems development process can be broken down into four phases:

• Planning
• Development
• Implementation
• Maintenance

The planning phase sets the stage for the success of the development effort. If not done properly, the budget and schedule may not be sufficient, the problem may not be adequately defined, the final project may not solve the business problem, and the right people may not be involved. The planning phase of systems development includes the following activities:

• Needs analysis: a study to determine whether a new system should be developed
• Current system review: a study of the current system to identify existing processes and procedures that will continue in the new system
• Conceptual design: preparation of the proposed system flow and other information illustrating how the new system will operate
• Equipment requirements: hardware configuration needed to process and use the new systems (e.g., processing speed, storage space, and transmission media)
• Cost/bene?t analysis: detailed financial analysis of the cost to develop and operate the new system, the savings or additional expense, and the return on investment
• Project team formation: identify people from programming, user departments, and support departments to develop and implement the new system
• Project plan: an overall project plan with defined tasks and deliverables to monitor actual results and ensure successful progress

Auditing can be involved in the planning process to develop an understanding of the proposed system, make sure time is built into the schedule to adequately define controls, and verify that all the right people are involved.

There is a definite correlation between a well-managed systems development process and a successful system. The use of a proven system development methodology increases the probability that the system’s internal controls will be effective and reliable. As discussed under the traditional development approach, systems development includes the following phases:

• Analysis: Define what is required of the new system.
• Design: Define how to build the new system to satisfy the requirements.
• Construction: Build the new system using the design information.
• Testing: Verify that the completed system meets the users’ needs and functions without fault.
• Implementation: Deliver the completed system to the end users; obtain satisfactory feedback.
• Maintenance: Modify the system as needed to correct problems or meet changing needs.

Auditing can review the development process to ensure the software is designed with user requirements documented, that management approves the design, and that the application is tested before implementation. An additional focus is ensuring that the end user is able to use the system based on a combination of skills and supporting documentation.

A Template for Formal Project Acceptance

This article describes the Formal Acceptance Document. This is just one example – I have other templates to provide at a later date – but I will go into some of the specifics concerning the document and provide some template text for the document itself. This is primarily for acceptance of a deployed system or project, but could also be modified to provide signoff for a specific deliverable document during the project such as a test plan or business requirements document.

Formal Acceptance Document

Purpose

The formal acceptance document captures the concurrence of the customer, sponsor, and other stakeholders that the project has been completed and meets its objectives. The most common form of formal acceptance document is the customer acceptance document, acknowledging that the project has been developed as the customer originally requested.

Application

Formal acceptance is used as the legal acknowledgment that the project deliverables have been delivered as intended. It is used to certify the project as complete and to release the project organization from any future obligations. Because of the important and heavily contractual nature of the document, it is normally developed early in the project and reviewed with the customer. It is then preserved and used during the phase or project closeout processes.

Content

A formal acceptance document may be presented as a form or a letter. It will provide detail on the date of origin of the project, the project name, and the degree (if not total) of acceptance. In that the document requires a customer signature and is normally initiated by the project organization, it must be designed to ultimately cycle back to the project organization after being signed. It may reflect any interim or milestone acceptance documents that have been exchanged, but should serve as the ultimate determinant that the customer accepts the deliverables as generated.

{Customer}

This letter is to certify that all deliverables under project [name/number] have been delivered in accordance with the contract/agreement dated [date]. Interim approvals for these deliverables were accepted and signed on [dates]. This serves as affirmation that the latest and final deliverables under the project agreement have been conveyed, and we seek your concurrence.

If there are any outstanding issues or concerns that have not been addressed please alert [name] of our organization as soon as possible. We have appreciated serving you in this effort and look forward to our ongoing relationship. Please sign two copies of this letter, keeping one for your records and returning the other to us via the enclosed self-addressed, stamped envelope.

[Signature]

X______________________ (Signature of Customer)

Date___________________

Approaches

Note that the customer acceptance letter does not go into a great deal of detail about the nature of the relationship, the type of work that was being performed, the level of effort, or the specifics of the project. In a formal acceptance document, the key is to reference a primary documentation source (like the contract) and to garner the customer signature. Some customers may perceive any supplements to the formal acceptance document as contractual addenda or as their approval or acceptance of certain behaviors or performance aspects that were not specified within the contract or project agreement.

As to the choice of a letter or form for formal acceptance, the letter creates more of a sense of professional warmth, whereas forms may be perceived as cold or pragmatic. Both serve the same function, but the nature of the relationship or corporate protocols may drive the use of one versus the other.

Considerations

Because the formal acceptance document requires a commitment on the part of the customer, and because that commitment releases the project organization from further obligations (except for those outlined in the contract), some customers may use the issuance of the formal acceptance document as an opportunity to extract last-minute concessions from the project organization. It is important to note that the acceptance document reflects the project as contracted, and although organizations may choose to accede to the customer’s late requests, any major shifts in project approach or delivery may need to be acknowledged as either contract addenda or within the body of the formal acceptance document.

Project Go – No-Go Decisions – Part 2

In Part 1 we looked at what brings us to the Go – No-Go decision point and how we review a project from both a justification standpoint, and a feasibility standpoint. In this Part 2, we’ll discuss how you go about reviewing the alternative solutions for your project problem and identifying the best solution with which to move forward.

Findinging the Best Solution

Once you fully understand the need and establish that satisfying the need is justifiable and feasible, you’re ready to determine the best way to satisfy that need. Although I’m using the term “you,” proper execution of this step really requires the input of many individuals. If you’re fortunate enough to be involved at this stage of the project’s evolution, you should be actively working toward building a team that can work with you from this point on.

Identifying Alternative Solutions

The process of identifying the optimal way to satisfy the project requirements begins with generating a list of potential solutions.

This process can be greatly enhanced in the following ways:

• Do it in a team environment
• Include subject matter experts and stakeholders as appropriate
• Use brainstorming techniques
• Limit further development to only reasonable alternatives

Selecting the Best Alternative

Obviously, you can’t pursue every idea identified through processes like brainstorming. After soliciting all reasonable alternative solutions, the project team needs to pare the list down to only those that are worthy of further development, investigation, and definition. You can reduce the list by compar- ing each alternative against predetermined criteria. This is where the Requirements Document begins to add significant value. The process for selecting the optimum solu- tion begins by evaluating each alternative solution in terms of how well it satisfies the most critical aspects of the project requirements, such as budget constraints or strategic alignment. You may also wish to use other requirements-based considera- tions, such as the likelihood of technical success or the antici- pated impact on existing products. This initial screening will allow you to shorten the list of potential alternative solutions to a manageable number—I would recommend two to five. At this point, the selection process becomes much more rig- orous. Each potential alternative should be evaluated using two basic types of criteria: financial and non-financial.

In Part 3, we’ll exam using financial criteria like net present value and cost benefit analysis to try to find the best solution and in Part 4 we’ll exam using non-financial criteria.

The Skill Set of the Project Manager – Another View

In my article “The Characteristics of the Project Manager,” I began what ended up being a five-part series and still probably needs a final summary article – assuming I’m done and have no more characteristics to share…which I probably do.

I’m always open to new and different information as well as different opinions on information I’ve already provided so far in articles on the PM Tips site. That’s why I’m presenting this excerpt from Gary Heerkens’ book entitled “Project Management.” It covers what he considers to be the overall skill requirements of a project manager. It’s not exactly the same concept as the characteristics of a project manager, but it’s close.

Skill Requirements of the Project Manager

To fulfill the responsibilities of the role of project manager and handle the challenges you’ll face, you’ll need very diverse skills and a wealth of knowledge. So what knowledge and skills does it take to be an effective project manager?

There are many ways to slice up this pie. The way that makes the most sense to me is to break it down into four major knowledge and skill categories:

1. project management process skill
2. interpersonal and behavioral skills
3. technology management skills
4. desired personal traits

Let’s examine each in detail.

Project Management Process Skills

Project management process skills (sometimes called the “hard skills”) are knowledge and skills related to the mechanics of project management. You should be extremely knowledgeable about project management tools, techniques, and process technology and be able to apply them. For example, you should be know how to prepare a comprehensive customer requirements document, construct a network diagram, and construct a work breakdown structure. Without these skills, you’ll find it very difficult to coordinate and facilitate the creation of a high-quality project plan and to maintain control during project execution. Also, since these skills are a basic expectation, you can expect to encounter problems of respect from your team members if you’re deficient in this area. As mentioned earlier, this skill set is the main focus of this book.

Interpersonal and Behavioral Skills

Since managing projects is all about getting things done through other people, your skills in dealing with people are of immeasurable value. Closely tied to your interpersonal skills are your behavioral skills: your personal conduct, style, and approach. Together, these two skill sets are often called the “soft skills.” Here are some examples of soft skills:

• team and individual leadership
• oral and written communication
• conflict resolution
• negotiation
• influencing
• delegating
• coaching and mentoring

For individuals coming to project management from a highly technical background, soft skill development can be particularly challenging. Later in this chapter we’ll discuss methods for developing these skills.

Technology Management Skills

Most projects have one or more embedded technologies. An embedded technology refers to the process or technology areas at the core of the project. Examples might include software development, chemical processing, or commercial construction. Your ability to guide and coordinate the application of these technologies is crucial to your success as a project manager. If you’re like Brad, you’ll probably have sufficient knowledge and skills in the primary embedded technology of the project. However, it’s likely that there will be several technology areas associated with your project. Although they will differ in focus, the process steps and related skills involved in managing their successful application will be similar.

Among these technology management skills are the following:

• proficiency in project’s core (primary) technology
• proficiency in supporting technology areas
• industry knowledge
• ability to prepare comprehensive technical specifications
• design skills
• product knowledge
• process knowledge
• management of intellectual property
• patent knowledge

Desired Personal Traits

Many studies have been performed to correlate personality traits to success as a project manager. Although each study reveals slightly different results, the traits shown in Figure 3-1 appear in most. Possessing these traits will stand you in good stead in your role as project manager.

• Honesty and integrity
• Thinks like a generalist
• High tolerance for ambiguity
• High tolerance for uncertainty
• Persuasive
• Assertive
• Process-oriented
• Self-aware/reflective
• Open and accessible
• Politically astute
• Decisive

Of these personal traits, I consider the following four to be among the most critical.

1. Thinks like a generalist—Project managers must always be thinking in terms of the big picture. This can be a challenge for those who are accustomed to focusing more narrowly. Although this trait certainly requires knowledge in many different areas, what’s crucial is that you must pay attention and care about everything and everybody.

2. A high tolerance for ambiguity—This competency will be particularly challenging if you’re technically oriented. You’ll often receive mixed signals or contradictory data. You need to develop processes for finding truth and narrowing down inputs without getting frustrated. This will probably not be easy for you.

3. A high tolerance for uncertainty—As with ambiguity, this is particularly challenging if you’re entering project management from the technical arena. Most technically oriented people are accustomed to precision. As a project manager, the norm is to make many decisions without sufficient information. You must condition yourself to making decisions that are only acceptable, not perfect.

4. Honesty and integrity—Although obvious virtues, these traits are worthy of specific mention. Whenever studies are performed on the traits that people most admire or desire in leaders, honesty and integrity always rise to the top. One of the best behavioral traits for a project manager is to be known as doing what you say you’ll do. Closely related is the issue of integrity, having a reputation as someone who will follow principles, even in the face of adversity or temptation.

Together, the combination of hard skills, soft skills, functional competencies, and personal traits compose the raw material for your overall capability as a project manager. But how should you develop that capability?

Skills that are somewhat mechanical can be learned or developed through self-study, reading, or facilitated training and practice. Many of the hard skills fall into this category. However, as you migrate toward the soft skills, the preferred mode of development moves from programmed learning to coaching or mentoring. Here, soft skills are best developed through observation and feedback from others— preferably those in a position to do so.