Project Management

How to Write a Business Case

Most of us have had to write a Return on Investment or a Business Case for projects we have worked on. The purpose of these documents is to define the overall benefits and costs of a project at a very high level usually aimed at Project Sponsors. The document allows you to provide much more diligence on the costs and benefits, while still not requiring you to actually go through the effort of specifying the work at this time. All Software Projects go through iterations of detail definition as more is known about the project. They key is to set the expectation of the degree of schedule confidence at each level of specification. At the Business Case Level the confidence in the schedule is very low.

When the Business Case is accepted by the Project Sponsor it is time to write a Project Charter and Project Scope Document which can be used to finalize the Project Plan and Work Breakdown Structure.  It is ideal to have the project team identified once the Business Case is accepted. If not, it is vital to have the majority of them identified by the time you finalize the Project Plan, Work Breakdown Structure and Schedule.A feasibility study is used to provide much more diligence and understanding about whether the project is feasible or not. In fact, the feasibility study might be a project in itself. The study might just be a more detailed analysis of the viability of a project and may not require a small project structure.

The result of the feasibility study is a document that is also called a Feasibility Study. There are a number of areas of feasibility that should be analyzed.

  • Technical. Is the project technically feasible? If it is you should state any technical risks associates with the project.
  • Financial. Is the project financially feasible? This would be especially important if the cost of the project was material to your company. It is possible that a project could have a cost that is significant enough to put the entire company at risk. You may have the ability to budget for the project now, but you might also analyze what the impact would be of a significant cost overrun.
  • Operational. You should make sure that you have the ability to run the products that are built by the project. It is possible that the project itself is feasible, but you may have significant risk in being able to operate the product after the project is over.
  • Geographic. Is the project feasible given the physical location of the project team?
  • Time. Is the project feasible given the amount of time it will require from the participants? This is a big worry on larger projects. You may have the budget to execute the project but you may realize you cannot free up the project team for enough time to execute the project. .
  • Resource. Do you have the staff, equipment, supplies and other resources necessary to complete the project?
  • Cost/benefit analysis (high level). You still have to complete the cost/benefit analysis as a part of the feasibility study.
  • Recommendations. The conclusions and recommendations should be noted. One technique that can be used is to look at a number of alternatives for how the project should progress (if at all). For each alternative discuss the benefits, costs and risks. This will show the reader that the right level of diligence was performed and that a number of alternatives were considered. Your final recommendation should address assumptions, risks, ROI (return on investment), estimated cost (with a confidence factor that is fairly low), priority and next steps to be performed.

All of this information provides further detail on the nature of your study and provides your management stakeholders with the complete set of information they need to make the best decision on how to proceed.

July 15, 2009 Posted by | Business Analyst, PMI, PMO, PMP | , | Leave a comment

Linkedin Profile

Check out my Linkdin Profile at www.linkedin.com/in/dritter5!  I’d love to hear your comments on what services you would like provided.

 

Donna

June 11, 2009 Posted by | Business Analyst, Living Your Best Life, Outsourcing, Phase Review Process, PMBOK, PMI, PMO, PMP, Project Initiation, Project Management, Risk Management, Schedule Management, Training, Writing and Documentaiton | | 3 Comments

The Nature of Project Management

Why do many talented developers and IT professionals consider project management to be an obstacle, rather than an enabler? Why do clients often resist project oversight or try to minimize it? Does project management really allow projects to reach completion more quickly, or are speed and project discipline mutually exclusive?

We’ve explored the balance of speed and delivery and the nature of innovative projects in recent articles. Let’s tie these themes together and review techniques that help keep project management relevant to even the most unique and innovative programs.

Project bureaucrats

When I teach project management, I often draw a distinction between project managers and project bureaucrats. We’ve all had encounters with project managers who turned into bureaucrats. Project bureaucrats are more interested in ensuring that every step of the methodology is applied and every line of every form is filled in than in what’s actually happening on the ground. On the other hand, it’s common to meet project managers who apply minimal project methodology, yet, through their expert use of relationships and personal interactions, always seem to know exactly where the project stands.

In my experience, it’s the project bureaucrats who often leave a bitter taste with both the delivery team and the client. These project managers turned bureaucrats have forgotten one of the key rules of project management: don’t mistake the map for the journey. All the plans, charts, and milestones mean nothing if they aren’t consistent with the reality on the ground. And there’s the rub; especially in innovative projects, the plans and estimates are often based on a fallacy — there’s the idea that we can predict the progress of something that’s never been done before.

Project spec compliance = success? Not always

In his outstanding book Agile Project Management, Jim Highsmith offers two examples that emphasize the point. The movie Titanic, from a project management perspective, was a huge failure — over budget, over schedule, and plagued by unforeseen risks that threatened to derail the project at every turn. Motorola’s Iridium project, which spent billions of dollars launching satellites into orbit in order to make telephone service available worldwide, was a great project management success. Yet the market is the ultimate judge, and the project management compliance of Motorola’s venture didn’t save the project from failure, nor did the project management disaster (no pun intended) of Titanic’s production taint the film’s appeal to the public.

The lesson that project managers should learn from these examples is that compliance with project specifications does not constitute project success; in the ultimate analysis, only business results matter. Stated another way, the largest risk in any project is not that it will deviate from plan; it’s the risk that the final outcome won’t fulfill the real need. Predictive methodologies, such as the techniques championed by the Project Management Institute in its PM Body of Knowledge, can add tremendous value, especially for projects for which we have a historical basis to look to for precedent. For truly innovative projects, in which any prediction is little more than guesswork and for which we’ll be inventing never-before-seen products, we need to look for a new approach. Hence, the growing popularity of agile approaches.

Agile myths and truths

The central insight of agile methods is not that project overhead is a pain in the neck or that programmers like to be free; instead, it is the observable truth that, especially in innovative programs, customers can’t describe what they want until they see it, and prediction is inappropriate when there’s no way to visualize what the final result will be, let alone exactly how long it will take to build.

Unlike predictive methods, in which the planning, estimating, and risk assessment activities are all front-loaded and often are seen as a separate “planning” phase, agile approaches assume that the requirements will grow incrementally and iteratively as the project proceeds. This emphasis on “just enough” planning and requirements discovery is an acknowledgement of the fact that the key up-front activity in an agile approach is the creation of the first iteration of the product, so that the sponsor can see it and touch it, and discrepancies between the sponsor’s vision and the product created by the team can be modified to fulfill the current business need.

Agile project management is often misunderstood, as illustrated by the proliferation of articles about “agile myths.” Agile methods are not about “buying pizza and getting out of the way,” as these methods are often caricatured. Agile methods, from SCRUM to Highsmith’s APM Framework, are disciplined and structured approaches to product development, just as predictive methods are; these methods just address different types of problems.

Predictive and agile approaches have robust requirements discovery techniques, but agile methods acknowledge that requirements will evolve throughout the life of the project rather than up-front. Both approaches have stakeholder participation practices, but agile methods insist that stakeholders and sponsors are involved throughout the project in a collaborative, interactive manner. Predictive and agile both have mechanisms for integrating changing requirements into the plan, but the approaches use different techniques. Predictive techniques often apply restrictive change management procedures. Agile methods are specifically designed to encourage and implement beneficial change by providing an iterative, incremental approach to development focused on implementing, rather than controlling, positive change.

Innovative projects call for innovative methods, but that doesn’t imply, as many agile skeptics insist, that the benefits gained by applying structured project management techniques must be abandoned. Agile approaches are appropriate for creative, inventive projects because the methods integrate exploratory, collaborative techniques into the project process and acknowledge the mutating nature of exploratory IT projects into the PM methods we apply. Even PMI, in its newly published Body of Knowledge, recognizes the value of the iterative, incremental approaches advocated by agile proponents.

More to come

In subsequent columns, we’ll dig a bit deeper into the specifics of some of these techniques and explore ways that agile approaches can be combined with familiar, predictive techniques to apply exactly the right level of rigor to the project, no matter where it falls on the innovation spectrum.

Get weekly PM tips in your inbox
TechRepublic’s IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

Rick Freedman is the author of three books on IT consulting, including “The IT Consultant”. Rick is a Director in the Global Services Division of NEC America, and a trainer and course developer in the Agile Project Management practice of ESI, the international PM training company.

May 28, 2009 Posted by | Communications Management, earned value, PMBOK, PMI, PMO, Project Management | | Leave a comment

The Role of the PMO in Organizations

Many organizations realize the benefit of developing and implementing a PMO. This is often true of those organizations employing a matrix organizational structure, and almost always true of those employing a projectized organizational structure, especially when the parent organization is involved with the simultaneous management of multiple and/or sequential projects.

 

A PMO can exist in any of the organizational structures, including those with a functional organization. A PMO’s function in an organization may range from an advisory influence, limited to the recommendation of specific policies and procedures on individual projects, to a formal grant of authority from executive management. In such cases, the PMO may, in turn, delegate its authority to the individual project manager. The project manager will have administrative support from the PMO either through dedicated staff or through a shared staff member. The project team members will either be dedicated to the project or might include staff members who are shared with other projects and, in turn, are managed by the PMO.

 

Project team members will report either directly to the project manager or, if shared, to the PMO. The project manager reports directly to the PMO. Additionally, the flexibility of the PMO’s centralized management can offer the project manager a greater opportunity for advancement within the organization. Specialty project team members can also be exposed to alternative project management career options in organizations with PMOs.

 

Project Management System

The project management system is the set of tools, techniques, methodologies, resources, and procedures used to manage a project. It can be formal or informal and aids a project manager in effectively guiding a project to completion. The system is a set of processes and the related control functions that are consolidated and combined into a functioning, unified whole.

 

The project management plan describes how the project management system will be used. The project management system content will vary depending upon the application area, organizational influence, complexity of the project, and availability of existing systems. The organizational influences shape the system for executing projects within that organization. The system will adjust or adapt to accommodate any influence imposed by the organization.

 

If a PMO exists in the performing organization, one of the functions of the

PMO would typically be to manage the project management system, in order to ensure consistency in application and continuity on the various projects being performed.[i]

 


[i] A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Third Edition

2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

November 5, 2008 Posted by | PMO | , | Leave a comment