CIOIN

Projects are short-term efforts to create a unique product, service or  environment, such as removing old servers, developing a custom e-commerce site, creating new desktop images or merging databases. All projects are constrained by three factors: time, cost and scope. For a project to be successful, these three constraints (often called the Triple Constraints of Project Management) must be in equilibrium. If any constraint is out of balance, the project is heading for disaster.

All projects, IT or otherwise, move through five phases in the project management lifecycle: initiating, planning, executing, monitoring and controlling, and closing. Each phase contains processes that move the project from idea to implementation.

According to The Standish Group, which tracks IT project success rates, only 29 percent of IT projects conducted in 2004 were completed successfully. The numbers are depressing for a variety of reasons. IT projects fail because they're just plain harder. They include the usual project-management challenges, such as deadlines, budget constraints and too few people to devote to the project. But they also face unique technology challenges, from hardware, operating system, network or database woes, to security risks, interoperability issues, and the changes manufacturers make to their hardware and software configurations.

IT projects fail at the beginning-not the end-due to a lack of sufficient planning. An IT organization must consider the resources it needs to devote to a project, the skills required and the people who need to be involved, and realistically consider the time it will take to create, test and implement the project deliverables. Otherwise, the project will be a mess. The IT organization will never complete it on time, on budget or with the required functionality, which are three common factors for project success.

Third, IT projects fail because they're rushed. Because so many companies today rely on IT for a competitive advantage, they speed through development efforts and systems implementations in order to be first to market with new, IT-based products, services and capabilities. Organizations often feel that, to remain competitive, they must cut costs and maintain business operations, but that adds to the pressure on a big, expensive project such as an ERP implementation or a platform upgrade. A project with inadequate planning, risk assessment and testing is doomed from the start.

Finally, IT projects fail because their scope is too unwieldy. A project with a large scope can usually be better executed by breaking it down into a series of smaller, more manageable projects. For example, a project to convert all of an organization's historical records, forms and transactions from paper to an online digital database can be incredibly complex and time consuming. A series of smaller projects allows for more manageable endeavors, such as first converting the existing records to digital, and then a second project to use the digital database internally, and then a third project to bring the database to the Web. These smaller projects can be completed sequentially and with more flexibility than a large, complicated and cumbersome project.

During the project's initiation, you should establish the criteria for success and failure. For example, to be considered successful, a project may have to adhere to certain quality standards (such as Six Sigma or an ISO program), fall within a certain budget, meet a particular deadline and/or deliver specific functionality.

Another approach is to use an indicator such as the "15-15 Rule." The 15-15 Rule states that if a project is more than 15 percent over budget or 15 percent off schedule, it will likely never recoup the time or cost necessary to be considered successful.

Certain management techniques can also help identify whether a project will be a success or failure. For example, the Earned Value Management technique allows an organization to measure a project's completion, schedule variances, create schedule and cost performance indexes, and forecast a project's likely completion date and financial impact upon completion. If, using the Earned Value Management technique, you see that a project is costing so much money that it's going to produce a quarterly loss, then you know it's not a success.

IT projects are canceled for a variety of reasons, though chief among them is poor planning. Cost overruns by more than 15 percent, late milestones and poor quality are also viable reasons for scrapping projects.

To determine if your project should be canceled, at the start, determine what circumstances would call for a project's cancellation. You might consider time and cost overruns, or shifting business conditions. For example, if your company experiences a significant or sustained dip in revenue for whatever reason, you may decide to cancel the project to save money. You might also decide to cancel a project if its scope has grown or changed so significantly that the project is no longer recognizable or has morphed into something else.

If scrapping it sounds daunting, you might wish to create smaller projects that give some return for the sunk costs. After all, smaller projects are more likely to succeed than large ones.

Organizations should create or adapt a standard approach to managing projects. Managers can quickly determine which ones are proceeding smoothly and which are not when all projects follow the same processes and approaches, and use the same metrics for measuring project performance. A standard approach to project management establishes ground rules and expectations for the project team. It also provides project managers, functional managers and the operational staff with a common language around project management that eases communication and helps ensure that everyone is on the same page.

Using a mishmash of project-management techniques makes it impossible for an organization to measure the success of its projects. And if they can't measure their projects, they can't determine which processes and methodologies are working and which ones need to be improved.

There are three leading approaches for managing IT projects. The first is based on traditional project management. It works with any IT project regardless of the technology involved or the duration of the project work.

The second approach is called Extreme Programming. It's sometimes abbreviated as XP (not to be confused with the Windows operating system.) Extreme Programming is a project-management approach designed specifically for software development. XP uses a software development model that involves the users, customers and programmers in four iterative phases: planning, coding, designing and testing.

Scrum is the final leader in IT project management. This approach, named after a rugby term, also uses iterations of planning, coding, executing and testing software. Scrum employs its own vernacular and has some rigid rules about meetings, hitting milestones and the duration of planning activities.

Many companies have adopted a project-management office (PMO) to centralize and coordinate all project-management activities, including IT, across a company. PMOs establish ground rules and expectations around how projects should be conducted for the project manager, the project team and the stakeholders. PMOs corral requests for changes to the scope of a project and provide training, tracking software, project plan templates and process forms to the project manager and the project team to help ensure that projects proceed smoothly and conclude successfully. In some companies, PMOs prioritize which projects are going to get done and when. They also say which resources will work on which projects to prevent departments from fighting over resources.

A well-rounded PMO is often led by a well-versed and experienced project manager and is staffed with support personnel who relieve the manager of busy work (keeping minutes from meetings, coordinating project records, communications and meeting with stakeholders.)

PMOs can exist inside or outside of IT departments. Some companies like to have one uber-PMO for all projects (whether they're IT initiatives, research and development efforts or new product launches) that's independent of all of those departments. Project managers typically report into PMOs. Dedicated project managers are often part of the PMO's staff, but employees who are named project manager for a given initiative are not usually part of the PMO's staff because they have some other day-to-day responsibility in addition to their newfound project-management responsibility.

The bad news about PMOs is that they can stifle project managers' leadership and management styles by dictating the methodologies project managers must use and by making them follow specific (and often tedious) procedures for documenting work.

Project managers need to be able to dictate the resources they need to complete a project successfully. If they don't have the authority to make the decisions about staffing, processes and methodologies that affect a project's success, their hands are essentially tied. By the same token, you don't want to give authority to an ineffective project manager.

Generally, the more experience a person has as a project manager, the more autonomy that project manager can expect. While this varies from organization to organization, the power structure within an organization often dictates the project manager's authority.

The jury is still out on the importance of certifications. On one hand, just because you're certified in project management doesn't mean you're a good project manager. On the other, if you're looking for a job in project management, having a certification distinguishes you from those who don't, and shows that you have documented, proven experience in project management.

That being said, there are three leading certifications for project managers: Project Management Professional, Certified Associate in Project Management and Project+ Professional. All of these certifications demonstrate the project manager's level of experience, education and knowledge of project management. The three certifications in order of prominence are:

* Project Management Professional (PMP). This is given by the Project Management Institute (PMI) and requires project managers to document their project management experience and the outcomes of the projects they have managed, and provide proof of educational experience. This documentation may be audited by PMI. PMP candidates must also take a 200-question, four-hour exam.

* Certified Associate in Project Management (CAPM). This certification, also from PMI, is for project managers with considerably less project management experience than their PMP counterparts. CAPM candidates must also document their experience, education and supervisors on their exam application.

* Project+ Professional. This certification is from the Computing Technology Industry Association (CompTIA), the same group that certifies A+, Network+, Server+ and other professionals. It requires that candidates pass an 80-question exam with a score of 499 or better in a 90-minute time period. The Project+ exam does not have the same pre-exam requirements as the CAPM or the PMP. This exam is ideal for candidates who aspire to manage larger projects or move into project management, or for recent college grads pursuing a career in project management.

Slow and fast are subjective terms; what may seem slow to your organization may be entirely zippy somewhere else. It's important to determine what's a reasonable time frame to complete an IT project based on the scope of the work, the expected deliverables and the conditions of the project.

That being said, you can determine if your projects are in fact moving slowly. Do you have historical information against which to compare current projects' speed, or have your projects always taken this long to complete?

Second, ask if your projects are effort-driven or of fixed duration. Effort-driven projects can be "crashed" by adding more resources to reduce the project's time line. Crashing a project, however, adds costs. If your project is of fixed duration, like testing software for two months before releasing it, there's not much that can be done to reduce the project's time line without increasing risk.

Projects that must comply with laws and regulations require more up-front planning. For example, in the age of Sarbanes-Oxley, you have to do a lot more documentation when you're developing a new business application or implementing new supply chain software. When project managers consider the regulations that govern their industry, from manufacturing to health care, the regulations become project constraints and result in more overhead. Factoring laws and regulations into projects also expands their scope and adds to their costs.

To get a good return on your investment, first identify what you want the project managers to know at the end of the project. Examine your projects and determine where the pain is. Are your projects failing in scheduling, planning, executing, communications? Everything? By determining where your projects need help, a project-management training provider can help your managers deliver better projects. There are plenty of off-the-shelf training solutions, but often an on-site class unique to your organization allows you to create a custom solution with more time focused on areas that need improvement and dismiss the areas your project managers have already mastered.