Successfully managing intranet projects is a challenging task. Most intranet managers have experience managing a particular area, such as a corporate information center, marketing, IT, or publication areas. We know one functional area or type of work extremely well and suddenly we're in charge of a multi-faceted project that requires multi-disciplinary and leadership skills, along with an understanding of other functional areas. The truth is, we're concerned most about the one area of the project about which we know the least. Non-programmers are most concerned about the technology. If you don't know the business unit, you're concerned about what the unit does and its particular needs. If you're unfamiliar with the end users or clients of the project, you're focused on whether they'll like, accept, and use the results of the project. As intranet project leaders we will likely never have expert knowledge about all aspects of a project. Rather, we need to create and guide a strong team with the expertise required to get the job done.
Intranet project success requires that several areas come together which basically boil down to people, technology, and money.
Before we get into these nuts and bolts, it's helpful to first define what we mean by project management. It's easy to think that the "intranet" is a project itself. It's not. One of the best definitions of a project is from Effective Project Management by Wysocki, Beck, and Crane:
A project is a temporary sequence of unique, complex, and connected activities having one goal or purpose and that must be completed by a specific time, within budget, and according to specification.
This definition tells us a great deal. In order to have a "sequence of unique, complex, and connected activities," we must have a methodology for designing the project. Since this project is "unique," it is not an activity that is routinely performed and, therefore, must eventually have an end. Once we've completed the project, we move on to another project. As there is "one goal or purpose" for the project, there must be a measurable outcome against which to judge the success of the project. This assessment is typically whether the project is completed within a "specific time, within budget, and according to specification."
Project management is the process of defining the extent (known as scoping), planning, staffing, organizing, directing, and controlling the development of an acceptable system at a minimum cost within a specified time frame.
Intranet project management differs from traditional management tasks in that project teams are usually cross-departmental workgroups that contain both technical and non-technical users, managers, information technologists, and sometimes, users of the project. Traditional, hierarchical command structures and permanent staffing patterns are not found in project teams. Instead, the team members are given responsibility and assigned to the project. Team members are often juggling their regular duties with multiple projects. Since the project team only exists for the duration of the project, once the project is completed, the team members return to their regular job duties. Because of this, it is not uncommon in some organizations for the project manager to be appointed from the ranks of the team. However, in other organizations (typically larger organizations dealing with very large projects), the intranet project manager is someone specially trained in the methods of project management whose primary job responsibility is to manage projects.
Ensuring Project Success
There are four key issues that must be addressed to ensure a successful project:
• The resulting system must be acceptable to the customer.
• The system must be delivered according to schedule.
• The system must be delivered within the budget.
• The system development process must have a minimal impact on on-going operations.
A project has distinct activities or stages within its lifecycle, and a critical component of a successful project is managing the project through these activities. Each stage presents risks and opportunities. For an intranet project, it is important to use a joint project planning approach. This means that all stakeholders in a project, including project owners, users, analysts, designers, and system builders, participate in the project development and agree on the project scope, schedule, resources, and budget.
1. Negotiate the Scope. The first activity in the project lifecycle is to negotiate the scope of the project. This includes defining the expectations of the project and outlining and scheduling all of the tasks and resources (including people) that will be needed. The scope of the project defines these boundaries:
• What is wanted at the end of the project and how will it happen?
• How good does it need to be and when does it need to be complete?
• How much can be spent on developing and implementing the solution?
• What resources are or can be made available?
The end result of this stage is the statement of work, which is a narrative description of the work to be performed.
Carefully consider what is supposed to happen when the project is over. What is your exit strategy? Are there some routine tasks that will need to be performed on an ongoing basis? If you don't plan upfront who will assume responsibility, as the project leader you can soon find yourself covered in barnacles from past projects—bits and pieces here and there for which you are somehow responsible. This is particularly true of intranet projects where the end result is a new system or workflow. There will likely be tinkering, fine-tuning and support required.
2. Work Breakdown Structure. Identify the work that must be performed in order to complete the project. Usually, these work items are defined in an iterative manner by starting with the largest concepts and repeatedly deconstructing them until all that is left are discrete, manageable units of work. This hierarchical decomposition of the work is known as a work breakdown structure (WBS) and results in the articulation of the project's phases, activities, and tasks. In some work breakdown structures, special tasks, known as milestones, are used as markers to indicate that a particular point in the project has been reached.
3. Estimating. You need to develop a timeline and estimates for how long it will take to complete all of the task projects. Estimating task duration is a stage in which many errors are made that subsequently come back to haunt the project. The most common problem is to underestimate the amount of time it will take for a task to be completed. This occurs for two reasons:
• The estimator fails to account for efficiency—no one performs at 100 percent efficiency, that is, no one works every single minute of the workday. People take coffee breaks, read e-mail, and go to the restroom. These activities must be accounted for when allocating people to work on tasks. Although it varies, most experts agree that most workers are only productive about 75 percent of the workday.
• Interruptions—people get phone calls, visitors, and other unplanned events occur; all of these will increase the time it takes a person to complete a task in process. For some workers, interruptions can take up to 50 percent of their time.
Some problems may be outside of your control. The classic problem is being given a project with unrealistic deadlines. This is a setup for failure. You must renegotiate the deadline or the scope. Here your skills as a negotiator are critical. It's often effective to offer the project initiator some choices—you can have X or Y.
4. Task Interdependencies. In the fourth activity, the task interdependencies are specified. The task schedule depends not only on the duration of individual tasks, but also on the interrelationships between tasks. The finish of one task can lead to the beginning of another, which in turn may require another task to be suspended for some period. Inter-task dependencies are a critical factor in determining overall project length.
A visual representation is usually the most effective way of representing the inter-task dependencies. For this visual representation, either a Gantt chart or a PERT chart can be used to map out the task dependencies. These are especially useful for determining the critical path of a project, which is the ordered sequence of tasks that will take the longest amount of time to complete.
A PERT (Project Evaluation and Review Technique) chart is a graphical model of the project in which the tasks are depicted in a network of relationships. PERT charts are used to make the interdependencies between tasks clear. The boxes in the graph represent individual tasks and the arrows on the connecting lines indicate the direction of dependency, that is, the order in which tasks must occur, by which the predecessor points to the successor task(s).
A Gantt chart, developed by Henry L. Gantt in 1917, is a simple bar chart that depicts project tasks against a calendar timeline. The tasks, represented as a bar, are listed vertically on the left of the chart, and the horizontal axis depicts the timeline. Gantt charts are especially effective for demonstrating how tasks overlap. Gantt charts tend to be more popular than PERT charts being easier to learn, read, prepare, and use.
Because the amount of record-keeping in a project can be quite extensive, project management software is commonly used to plan projects, develop schedules and budgets, create and maintain Gantt and PERT charts, and monitor progress and costs. Some of the most common project management software packages are listed in Table 1.
Table 1: Representative Project Management Software Packages
5. Resource Allocation. By the time you reach the fifth activity, a theoretical schedule exists. However, until the required resources have been allocated, the project schedule isn't complete. These resources include accounting for the people, services, facilities and equipment, supplies and materials, and money needed to complete the project. Once these resources have been assigned, it is possible to develop a schedule and budget.
6. Development. This is the stage in which you manage and control the project. This activity usually lasts the longest. You make sure that schedules are being adhered to, costs are not spiraling out of control, and problems are identified and solved. It is important for the project manager to understand that the project team will move through stages of development and, at first, tasks may not move as quickly as one might desire.
At first, the team will be primarily concerned with establishing its structure and rules, clarifying relationships, and developing a plan to achieve their goals. A bit later on, ideally, the group will develop a participative climate after any interpersonal conflicts (that started in the prior stage) have been resolved. The ad-hoc nature of many intranet projects can pose unique challenges. Many of the players do not know each other. They may work in physically disparate areas. To facilitate the creation of the team, some project managers will arrange opportunities for the team to meet outside of work on an informal basis or encourage informal coffee or lunches at work. As the project starts moving forward, the team continually develops better means of providing feedback to each other and methods for sharing ideas.
During this stage of the project, you are usually busy with regular progress reporting controlling change within the project (changing requirements or expectations), and making adjustments to the schedule based on progress within the project. It is vital that the project manager regularly monitors the progress of tasks within the project and makes adjustments to the schedule expeditiously when needed. A large factor in many project failures is the failure to recognize when adjustments to the schedule need to be made. Brazenly moving forward when the evidence tells you to either slow down or stop and reconsider is an invitation to project disaster.
7. Assessment. The last activity of a project, and the most overlooked, is assessment. Did the project meet or exceed the requestor's expectations? If not, why not? Did the project come in on schedule? If not, what caused the schedule to go over? Did the project come in under budget? If not, where did the budget go over?
The results of this assessment should be communicated to all of the parties involved in the project. Because much can be learned from these assessments that will be of use in future projects, the project manager shouldn't ignore this opportunity.
Avoiding Failures and Pitfalls
So, why do projects fail? Projects fail for several reasons, but the reasons are not unique. In fact, most of the reasons can be seen over and over again:
Taking shortcuts through the system development methodology—this is perhaps the most common and most costly error made. This is often done because:
• the project gets behind schedule and the team wants to make up time.
• the project is over budget and the team wants to make up costs.
• the team is not trained or doesn't really understand the methodology's activities and so they are circumvented. None of these are valid reasons and all will lead to failure.
• Failing to establish organizational commitment to the project—if the organization as a whole isn't interested in the project, why are you doing it?
• Failing to establish commitment for the development methodology—if the development methodology isn't followed, it's little more than adornment for the bookcase.
Poor expectations management, typically represented as:
• Scope creep—the unexpected and uncontrolled growth of user expectations and requirements for an information system as the project progresses.
• Feature creep—the uncontrolled addition of features or functionality to a system in development without regard to cost or schedule.
• The project is simply not necessary or seriously misguided—the mandate has come down from the top to deliver on it.
Premature commitment to a fixed budget or schedule—commitments related to time and money shouldn't be made until you know what you're actually supposed to be doing:
• Poor or overly optimistic estimation techniques—"guesstimation" is not an estimation technique that works very often and neither is really hoping that everything will work out for the best.
• Adding resources to overcome schedule slippages—it is a well documented fact that adding personnel to a project that is in trouble does not speed up development but, in fact, slows it down even more.
• Inadequate people management skills—this problem is easy to identify; if not one seems to be in charge, then no one is.
Conclusion
The most important skill for a project manager to have is the ability to work well with people. Sometime we need to lead, sometimes we need to stand back, and other times we need to push from behind. As a project manger, our job is to keep the project on track. Everyone on the project team has a role and job to do, but someone must steer the ship. One experienced intranet manager described his key role as "removing obstacles" so the team can get the work done. In fact, much of what we do as project managers is just that—trying to plot the best course, making changes in direction, and removing any obstacles that pop up along the way. Great project managers are natural contingency planners. They appear calm on the surface but underneath they're always thinking, "What will we do if this happens?"