1.4. Project Success Factors
There are numerous things companies and IT managers can do to increase the chance of success for any IT project. We'll look at these success factors in the order in which they currently impact project success. Over time, these factors tend to shift positions, but the list itself has remained fairly constant. If you're trying to make the case for implementing project management in your company, you may want to pay special attention to this section. It will provide you with critical data that you can use to present the case to your senior management team or to convince other stakeholders in the company of the importance of PM practices. In each of the segments below, you'll learn about a different success factor and how you can use or implement it in your organization. We'll return to each of these items in later chapters in the book and provide detailed steps you can take to improve your project outcomes.
1.4.1. Success Factor 1: Executive Support
Executive support is the number one factor impacting project success. Of course, that probably doesn't come as much of a surprise. If executives are not supportive, they're unlikely to assign needed resources (labor hours, dollars, equipment, etc.) to the project. Additionally, they're less likely to defend the project if it runs into trouble or gets bogged down in corporate politics. Executive support can also help ensure that cross-functional teams deliver on their assignments, especially when projects cross departmental and divisional corporate lines. Finally, executive support can give a project company-wide visibility, which can be good or bad, depending on how the project turns out.
1.4.2. Success Factor 2: User Involvement
The lack of user involvement is number two on the list only because if the project never gets out of the gates, it won't succeed, so executive support is the first success factor. However, coming in a close second is lack of user involvement. Here's what typically happens: Someone comes up with an idea for a project. A team is put together to evaluate and implement the project. The project starts up and about three-quarters of the way through, someone might mention getting the users trained. In the worst-case (and fairly common) scenario, once the project is complete, it is implemented and dropped on the users. Often user input and training comes after the fact or not at all. In a better scenario, users are involved in designing the project and trained sometime before the project goes live. If you're like most IT folks, right about now you're saying "Yes, but…." Read on.
Many IT managers find it difficult to involve users early on for two key reasons. First, users are typically uneducated about IT processes, whether it's software development or infrastructure upgrades. Without understanding how things work in IT, most users come up with fairly unrealistic expectations about how and when things should be done. Think of it as a culture clasheach culture (IT and user) is right within its own sphere, but a lot gets lost in translation. Users' requirements can seemingly change from day to day and their understanding of what it takes to get the job done is limited. If users don't understand the process, they may inundate IT with a barrage of questions the IT staff is unprepared (or unable) to answer at that point in time. To avoid this onslaught of user questions, IT staff often delay communicating with users.
A second big complaint from the IT department is scope creepthe requirements for the project keep growing even as the project is underway. The source of this scope creep is often the user community. On the other side, users complain that they are left out of the loop until it's too late to make any meaningful changes to the project. As a result, both IT staff and users become frustrated.
From a user perspective, the IT department often comes in, asks a few questions and months later unveils the new system, application, or solution. Users are not asked about requirements ahead of time, are often not involved in usability and functionality testing, and sometimes are not trained until after the fact. This leads to user confusion and dissatisfaction. There is a better way. We'll discuss how to turn users into allies rather than opponents later in this book.
1.4.3. Success Factor 3: Experienced Project Manager
In recent years, it's become clear that having an experienced project manager at the helm has a significant impact on the success rates of IT projects. In the 1990's, there was little call for formally trained (or experienced) project managers only because project management as a business practice was not as in demand as it is today. While project management has long been utilized in many large, industrial companies and governmental agencies, it has now become almost a de facto requirement even in small and mid-sized companies. The evidence is clear and overwhelminghaving a trained, experienced project manager has an enormous impact on a project's chance of success. Experience becomes a more important factor as the project size, cost, and timeline increase. In fact, according to the Standish Group's research, 97% of all successful projects have an experienced project manager. We'll discuss the role of project manager and what skills and traits are important for success as a project manager later in this book.
1.4.4. Success Factor 4: Clearly Defined Project Objectives
For most people familiar with project management, success factor 4 is painfully obvious. If that's the case, however, it's hard to explain why a vast majority of projects don't have clearly defined objectives. It's one of those things like daily exerciseeveryone agrees it's good for you, but it's just such a nuisance to actually do it. There are a number of reasons why projects lack defined objectives. Laziness is one explanation, of course, but not the best one. Most of the time there are numerous organizational factors including politics, shifting priorities, cash flow/financial problems, extremely tight timelines, and organization restructuring that sometimes make defining project objectives difficult or impossible. Project objectives essentially define the scope of the project. The scope is the total amount of work to be accomplished. If these are continually changing, it's like trying to hit a moving target. Later in this book, we'll take a close look at objectives and give you specific tools you can use to create well-defined project objectives. We'll also discuss how to get buy-in from appropriate stakeholders so those objectives don't shift on you (too much).
1.4.5. Success Factor 5: Clearly Defined (and Smaller) Scope
Studies have shown that the longer a project runs (scheduled duration), the less likely it is to be successful, so there is an inverse relationship between project success and time. Scope, defined as the total amount of work to be accomplished, is inextricably linked to timethe more work that needs to be done, the longer it usually will take. The scope of the project is reflected in the project's objectives. Some IT project managers prefer to start with objectives to see how those define the scope; others prefer to start with the scope and develop the objectives from there. We'll discuss the process of defining scope and objectives later.
Clearly, there is only so much that can be accomplished in a given amount of time. Despite our impulse to throw more bodies at some problems, studies have shown that in many cases there is an inverse relationship between the number of people working on the problem and the time it takes to resolve the problem. To put that in plain English, in some cases the more bodies you throw at a problem, the longer it will take to fix it. This might explain why you always see six highway construction workers standing around while one guy does all the work…OK, that might not apply, but how many people can write one section of code or install one server? You may be familiar with the expression, "a camel is a horse designed by committee," which sums up the challenge of having too many people working on one problem.
Typically, the only way to reduce the amount of time spent on a project is to limit the scope of the project. Scheduling efficiencies may reduce the timeline, but rarely reduce the amount of effort required to complete the project tasks. In many cases, it is worthwhile to break large projects down into smaller, shorter projects. Smaller projects are more manageable and often give the project manager and project team more flexibility with limited resources.
1.4.6. Success Factor 6: Shorter Schedules, Multiple Milestones
You just read that time is the mortal enemy of project success, so it should come as no surprise that the next success factor is shorter schedules with more frequent checkpoints. Scope defines the total amount of work to be accomplished and the schedule defines the shortest possible path to accomplishing that work. If the schedule starts getting longer, there's a good chance your scope is creeping on you and that will directly reduce your chances for success. The schedule is developed based upon the availability of resources and the skills of those resources. We'll discuss scheduling and resources when we look at the planning phase of project management.
Studies have also shown that projects with more milestones placed closer together are more successful. This also makes sense when you think about it (of course, most of us just don't stop and think about it). Milestones, by definition, are tasks in your project plan that have no duration. They are simply markers to help you navigate through your project plan and indicate important checkpoints or events. They can be project phase transition points; points at which external data, resources, or decisions must be gathered, or simple checkpoints. It makes sense, then, that the more often you have a checkpoint, the more successful your project is likely to be. The sooner you notice the project is heading off-course, the easier it is to make small adjustments. Of course, all things (including milestones) in moderationtoo many checkpoints and you'll drive yourself and your team members crazy.
1.4.7. Success Factor 7: Clearly Defined Project Management Process
Has it struck you yet that "more time, more money, more people" are not on the success factor list? What is on the list includes getting the right people involved and clearly defining some key project elements. Sound basic? It is, though it is certainly easier said than done. Having a clearly defined project management process comes in at number seven on our countdown, but odds are good that if you have an experienced project manager (success factor three), he or she is using a clearly defined PM process already. If that describes you, hang on. We'll discuss that process and ways you can improve your own PM methods throughout this book.
A clearly defined project management process is important for project success for several reasons. First, when processes are clearly defined, you avoid reinventing the wheel each time and you can re-use processes that worked and tweak those that didn't. Over time, this leads to improved processes that can easily be implemented by members of the project team. Also, clearly defined processes reduce or eliminate some of the project re-work. Think about the last time you went to the hardware or grocery store. If you had a list, you had close to a 100% chance you'd leave the store with all the items you needed. On the other hand, if you didn't have a list, you had close to a 100% chance that you'd leave the store without something you did need and with several things you really didn't need. The same holds true in project management. Having well-defined project management processes helps you do the right things in the right order without having to give too much thought to the process.
There's also an efficiency that comes with having well-defined, easy-to-use processes. If the process by which you got paid by your employer changed each pay period, imagine the confusion it would cause. The time wasted tracking down missing paychecks and responding to frantic or irate employees would take far more time than the payroll department could handle. Instead, there is a consistent process and everyone knows not only when and how paychecks are distributed, but they also know what to do in the event a paycheck is missing.
Before we leave this topic, let's make one thing perfectly clear. Process for process' sake is a waste of time. We're going to focus on simple, easy-to-use processes that actually make your job easier. The processes in this book are excellent tools for managing your project, not excellent ways to waste more of your valuable time.
1.4.8. Success Factor 8: Standard Infrastructure
The last major success factor we'll discuss is using standard software infrastructure. Clearly, this applies directly to software development initiatives, but it can also be applied to other IT projects. According to the Standish Group research, 70% of all application code is considered infrastructure, which means that the other 30% is the custom code. Standardizing the infrastructure of the code's foundation leads to both efficiency and stability in the code. Some of the infrastructure code is unique to the application, but often there are components that can be purchased from an infrastructure vendor to alleviate the need to develop unique infrastructure solutions. Relying on off-the-shelf infrastructure components increases the chance the development project will come in on time, on budget, and with required features. Developers can focus on the competitive or strategic elements of the code (what separates your product from your competitors) instead of developing the infrastructure.
If you're not developing software, this success factor still applies to you. Projects that use standard infrastructure components are more likely to be successful. Most IT pros who work on the hardware end of things will tell you that things almost always work better when the infrastructure components are standardized on particular platforms and even with particular vendors. Mixing and matching often creates compatibility issues that hardware folks hate to chase down. Standardizing the infrastructure used in your project, regardless of where in the IT world your project falls, will generate greater success.