Section 1.4. Project Success Factors

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.

Applying Your Knowledge

As you'll learn in later chapters, having a project sponsor is important to project success. Often the project sponsor is an executive in the company. Your job is to provide that sponsor with accurate, useful, and appropriate information about what the project will look like, what the project will cost, how long the project will take, and perhaps most important, why the project should be undertaken. You can and should use your team members as resources when compiling project details and you'll learn exactly how to do this when we discuss project planning later in the book. Even if the person that assigned you the project is the project sponsor, it's still important for you to provide the information he or she will need to support and defend your project in the future. You'll learn more about this later in this book.

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.

Applying Your Knowledge

Involve users early but through a very well-defined and managed process. Look for subject matter experts (SMEs) within various user segments and work with these user representatives. Set clear expectations about their participation, and when the requirements are agreed upon, they should be "etched in stone" to prevent scope creep. Developing requirements documents is not a simple task and it will take practice to get your skills where they need to be, but it is well worth the effort. We're going to devote a fair amount of discussion to this topic later in the book because getting users on board with the project early on will absolutely impact your project's chance of success. You'll learn how to effectively manage user involvement so you don't get yanked in every direction, and we'll discuss specific methods you can use to gather user input while managing the project requirements. We'll discuss scope creep in more detail when we discuss project planning and change management later in this book.

Enterprise 128…
Users, Users Everywhere…

The following is a true story. No names are used to protect, well, everyone involved. A software company was developing an advanced application to manage financial data for non-profit organizations. The target market had been making do with a handful of homegrown applications built on legacy platforms (DOS, for example). This new application was going to transform the marketplace and would be in huge demand, or so went the story. As the first couple of beta customers tested the product, the response was overwhelming. "Where is the reporting capability?" Didn't customers notice the new, easy-to-use interface? No. Didn't they notice the ease with which they could manage funds from different accounts? No. What they noticed was the one (missing) feature every customer had mentioned during customer meetings, focus groups, and surveys: reporting.

What went wrong? The development team prioritized the bells and whistles higher than reporting features. In every development meeting, user requirements (reports) were de-prioritized to make way for either critical fixes or features that some believed would be a deciding factor in future sales. Though the client side was represented by two or three lonely voices, there was little support at the top of the organization for these user requirements. As a result, the engineering department took their cue from the top and repeatedly de-prioritized the reporting features.

There is a happy ending. Once engineering focused on getting the users 90% of the reports they needed and wanted, the client's resistance to the product melted away and the new application was enthusiastically received in the marketplace.

Lesson Learned: Find out what the users need and want. Spend time listening, not talking. Understand how users currently use the technology and discuss what needs to change. Then, prioritize the items on the user lists. Confirm the required and optional features with subject matter experts. Make sure you understand what the "must have" features are and deliver on those. Get agreement from the users on the final list. You may have to negotiate because often you can't deliver on everything. It's better to have 100% of 10 features than 10% of 100 features. Next, lock down that list. If you need to, shorten the list for the first iteration and work on subsequent priorities in later releases. Although this software company spent time gathering user input, it never incorporated that into a firm list of "must have" user-side requirements, sometimes referred to as acceptance criteria. If they had, the product probably would have gained traction in the marketplace about 18 months earlier than it did. Not all stories end as happily.

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.

Applying Your Knowledge

This data gives you a great selling point if you need to get top management to pay for formal project management training for you, your team, or your company. Even if formal training isn't on your agenda, you can get buy-in for assigning strategic projects to the most experienced project managers. While that sometimes means shifting in-progress projects to other project managers, your goal should be to assign your most complex, strategic, and/or critical projects to your most experienced project managers. If you want less experienced project managers to gain expertise, assign them as team members on important projects and let them learn from the best. If you're an experienced project manager, applying the processes defined in this book will add consistency to your projects.

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).

Applying Your Knowledge

Clearly defined project objectives comes in at number four on the list of key success factors. The first three success factors have to do with peoplethe executives, the users, and the project manager. This is the first factor internal to the project itself that appears on the list and is the most important project-specific aspect. Knowing this will help you get all the stakeholders (anyone impacted by the project or the project's outcome) aligned with the project's objectives. As with other elements, it may take some negotiating on your part to lock down these details, but if everyone understands the impact of clearly defined objectives on the project's success, you're more likely to gain agreement on the top-level items.

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.

Applying Your Knowledge

Resist defining or managing big, complex projects. Some people see these as a chance to make a name for themselves. That's true, but it won't be a name you like when the project fails. If you're assigned a large, complex long-running project, try to break it down into smaller projects (sub-projects or phases) in a manner acceptable to senior management. Work diligently to define scope and prevent scope creep. One method that works is to define both what the project does and does not include. When you define what the project does not include, there's less room for confusion about the actual scope of the project. We'll discuss this in greater detail later in the book.

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.

Applying Your Knowledge

Take a look at the average or typical project length at your company or within your IT department. Then look at the success rates of those projects. Since there is no specific definition of "short" or "long" duration, look for the intersection of project duration and project success in your department. While there are numerous other factors at play, you might be able to find the optimal project duration for your purposes. If not, break big projects into smaller projects then set shorter schedules with multiple milestones. We'll discuss schedules and milestones later in this book.

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.

Applying Your Knowledge

First, you can use this information to generate buy-in for using a project management process. Some companies are more reluctant than others to implement new processes or systems. However, using the information in this chapter, you should be able to create a compelling case for using project management. Also, once you've read through this book, you'll be able to develop clearly defined project management processes for your department or team. You'll then be able to implement and modify the project management processes your IT team uses to reflect the unique needs of your situation. You should learn the process from start to finish before you decide to modify anything, but once you have a good feel for the processes, feel free to tweak them to suit your company's needs and business methods.

Cheat Sheet…
What Projects Really Cost

It's been estimated that 50% to 75% of the total cost of any project is directly attributable to errors, omissions, and re-work. Think about that for a moment. A project that's estimated to cost $500,000 will cost almost $1,000,000 or more and all of the difference is probably directly related to errors, omissions, and rework. While having well-defined project management processes won't prevent all project problems, if you could reduce errors and re-work by half, you'd save 25% to 38% of the total cost of the project.

Here's another estimate related specifically to software development. It costs approximately 100 times more to fix a software problem after the product has been released to customers than it does to fix the problem during the development phase. Clearly, cost savings (and numerous other benefits) come from testing and quality processes built into the project management process so problems and errors are detected and resolved early.

The best part of the deal is this: if you implement these processes and reduce errors, omissions, and re-work, you not only reduce the total cost of your project, you also probably reduce the time it takes to complete the project and deliver higher quality as well. There aren't too many free rides in life, but this is one of them. We'll discuss these processes in detail throughout the remainder of this book.

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.

Applying Your Knowledge

When developing your project plan, look for opportunities to use standardized componentsfrom software infrastructure elements to hardware infrastructure elements to templates and off-the-shelf solutions. Carefully analyze the cost of purchasing infrastructure versus creating your own. Small and medium-sized companies often fall victim to the "it costs too much" mentality when looking at off-the-shelf solutions to incorporate into their products or projects. However, if you add in the cost of errors, omission, re-work, and cost and schedule overruns, you'll more than likely find that purchasing these components or elements is a better business decisioneven if it costs you more initially than you expected. When we look at developing a project budget, we'll discuss how to evaluate some of these items.

The IT Factor…
Using Standard Components

Remember the software company that ran into trouble because it lacked the reports customers required? A missed opportunity was to purchase a report engine and incorporate it into the product. At the time, the company was tight on funds, as are many startups, and top executives made the decision that developing the code for reports would be more cost effective than purchasing a report engine. On the surface, that appeared to be true when you look at the cost of that kind of component. However, there are a number of things they did not consider. For instance, how many programmer hours did it take to develop these reports? How much expertise did the programmers have in developing reports versus a company whose business it is to develop and sell a report engine? How likely or possible would it be to continue to upgrade and improve the reporting functions as technology changed? What was the opportunity cost of developing those reports in-house (meaning, what did those programmers NOT work on because they were busy developing reports)? Finally, what sales/marketing benefit (if any) would there be to using a well-known, widely used report engine? Had these factors been considered, it's possible the company may have chosen to use a standard report engine, despite the high initial price tag. There are times using standardized components makes sense and there are times when it does not. The key is to clearly define objectives, identify alternatives, evaluate the feasibility (including cost, risk, etc.) of each alternative and implement the best solution. We'll discuss identifying departmental strengths and weaknesses in Chapter 2 and evaluating alternatives in later chapters.