Managing software projects at AT&T
common risks and pitfalls
Rhoda Ondov, PMP, Technical Manager, AT&T Labs
The Technical Assessments Group of AT&T Labs, formerly a part of Bell Labs, has been evaluating software projects across the AT&T companies for over 10 years, covering hundreds of projects of all types. While this is a small percentage of the overall projects within AT&T, the work does offer us a unique opportunity to see problems that occur in a broad spectrum of projects. With this background we can share our knowledge learned to help other projects achieve success. Although these projects are internal to AT&T, they are much like projects attempted at many other large companies, and the issues encountered are similar across the IT industry.
This paper addresses the problems in the context of the PMBOK® Guide project management phases—initiation, planning, execution, control/tracking, and closeout, and will present examples to illustrate some of these issues. Specific identifying details will be omitted from any examples, but you will surely recognize similar situations in the projects you have seen. Included in the discussion will be highlights of those areas where projects are succeeding, emphasizing improvements in project management practices within AT&T. Following this discussion will be a summary of some trends we see in the types of projects being undertaken, and what challenges these trends present. Finally, recommendations are proposed for dealing with these problem areas and challenges.
We are a small group of very experienced software professionals with both technical and organizational skills, and we operate as internal consultants to review projects for a variety of reasons: to assess project health, identify organizational issues, for assurance of proper planning, or to overcome a troubled situation. We perform three major types of assessments: operational, architecture, or vendor. This discussion will focus on the “operational” or project management assessment. We also perform assessment-related short-term consultative engagements, and offer the quarterly delivery of an Architecture Seminar (highlighting the principles and patterns of system architecture).
The operational assessments are generally project-wide evaluations with a focus on the key areas that have been historically shown to impact project success. These areas run the gamut of business alignment and governance, organizational structure and dynamics, project management, communication, roles and responsibilities, the service realization approach, development life cycle (requirements, design, code, test, rollout, maintenance), architecture, technology, and more. However, the topics and specific goals are adapted to the project and the type of assessment (e.g., retrospective vs. in-progress, troubled project vs. health check). This discussion will be limited to the areas related to project management; problems in more technical areas such as architecture, implementation, testing, and technology will not be addressed here. However, it is important to note that many “technical” problems can be the result of poor project management practices, such as inadequate scope definition, or incomplete planning.
The operational assessments consist of two to three weeks of planning and preparation followed by an on-site visit of one week by a team of four assessors. One member of our group leads the review, and enlists subject matter experts in relevant project areas—other team members or in-house or contracted staff. Our findings are reported to the project for their internal use in achieving success. We also provide a full written report. We maintain an internal taxonomy of our assessment findings including things done well. These are categorized by major area of impact. The issues tracked represent the limited set of projects that have enlisted our expertise to help them address outstanding problems. Interestingly, about 50% of the project issues deal with either project management or requirements (closely related to project management) as shown in Exhibit 1. It is these areas that we will explore in further detail.
Project Management Issues
Of the issues noted for projects that are experiencing problems in meeting customer expectations or deliverables, the most difficulties occur in the project initiation and project planning phases. We will look at these and the other phases in more detail in the following sections, along with the major types of problems seen. A basic knowledge of Project Management phases and knowledge areas is assumed, but Exhibit 2 will serve as a reference for these as we look at each phase.
Exhibit 1. Assessment Problem Areas
Exhibit 2. Project Management Phases
The initiation phase is a critical time for projects, and it is important to start out right and set objectives. Knowledge areas playing an important role in success here are scope management, in defining scope as well as setting ownership, and managing time and cost, for high level estimates.
Unclear Business Problem and/or Success Criteria
We ask each project to answer the question: What problem are you trying to solve? Often project team members do not offer consistent responses to this question or they offer differing perceptions of what business problem is to be solved. The project may be moving forward while solving the wrong problem. It is very easy to get caught up in implementing a solution that is elegant, or interesting, or simple, or just familiar, without stopping to ensure that it is appropriate for the true need, or even that the true need is understood. Another gap in understanding the business need is the lack of clear criteria to measure success. Projects experiencing this difficulty are unable to articulate what constitutes success for the project.
Example: On one project, objectives had changed substantially since the project began, and even the target market had shifted; yet, this was not formally acknowledged, and the project plans did not reflect the revised goals. Not surprisingly, the project team could not reach agreement on several decisions needed to create a viable product. It is difficult to be successful without clarity on what it is being built.
Lack of an Executive Sponsor or Champion
Without full commitment at the leadership level, a project will flounder. This can occur when there are many projects in a portfolio competing for priority and resources. Clear ownership and support are necessary to focus resources within the project or with other supporting teams. Our assessment process provides a forum where the management and development teams can identify open issues and offer alternative solutions to spur decision-making and acceptance.
Multiple People as Project Manager (Or No Real Project Manager At All)
When a committee attempts to function as the project manager, it is unlikely to succeed. While in theory it may be possible for this arrangement to work, we have witnessed many difficulties ranging from delays in responsiveness and decision-making to a lack of unified issue resolution. More commonly, though, the role of project manager is assigned without sufficient authority, which leads to an inability to acquire true commitment for deliverables. Even a project with a well-documented robust project management process may not actually allow the project manager to execute the stated authority over the scope, budget, or end-to-end management of priorities or resources on the project. The function then becomes primarily administrative support handling facilitation, tracking, and coordination, leaving a void in the management of the project. Occasionally, we find projects where the team members are unable to identify or name the “one” in charge.
Example: On one project, three managers operated a steering committee that functioned as the “project manager.” Unfortunately, while the managers felt comfortable with this arrangement, the team members noted the lack of decision-making and priority setting that hindered progress on key deliverables.
Scope/Size of Effort Under-Estimated
Up-front or ballpark estimates are by definition less than completely accurate, but we often see a significant amount of over-optimism on the effort required for the project. Although further definition typically increases the scope and complexity for any project, allowance for these unknowns may be inadequate or missing. Then, because the change is seen as clarification rather than outright scope addition, extending the date first estimated is not agreed to. As a result, once the full detail is known and implemented, it is likely to be late and over budget.
Example: One particular project required several features that were dependent on a more robust infrastructure than the existing platform provided. Unfortunately, this important dependency was not initially recognized or acknowledged. The needed infrastructure enhancements were then gradually added to the project plan as it was defined, until the scope became unmanageable and looked more like a business reengineering project.
Unrealistic Expectations of COTS (Commercial Off the Shelf) System
This is becoming a bigger problem as more organizations look at the use of COTS systems to increase efficiency and control costs. What is sometimes overlooked, however, is the tradeoff that must be made to achieve these benefits. The COTS system generates its economies by providing a generalized solution suitable for many customers, so that each company purchasing the product is in effect sharing the development cost. Although customization is usually available to tailor the product to specific installations, organizations may overuse this option. This results in so much custom code that the development and maintenance cost of this code, when added to the original product cost, creates an end product as costly, or even more so, than a custom solution, and with less flexibility. This can occur when the project has not adequately defined the business needs or has not properly evaluated the COTS product capabilities (or both), and there was not really a good match to begin with. At the same time, the organization may not want to consider adapting their business practices to the product requirements, opting instead for more customization. With the additional time and cost for customization not anticipated in project plans, the expected project benefits do not materialize.
Example: There is one case where the project assessed reached 250K lines of undocumented custom code imbedded in a solution based on COTS.
End Date Predetermined Without Recognizing Implications
Though it is not unusual for a project to require completion by a given date, this must be done with the realization that if the time constraint is fixed, the scope and cost constraints must be more flexible. These tradeoffs, as well as the increased risks undertaken with a project of this type, are sometimes not acknowledged. We do see projects where a predetermined date is really more of a political statement. While this can be a valid motive, for reasons such as bolstering the reputation of a maligned IT organization, it can also be approached with an uncompromising “dig in the heels” attitude. When the deadline justification is of a more compulsory nature, say a legal requirement, we usually see a more pragmatic approach to negotiation.
The planning phase is the road map for the project—and where requirements definition and schedule development take place. It is essential to take the time to plan properly, but we see some projects rushed through this phase in a misguided attempt to save time. In fact, the project planning phase has the highest occurrence of issues recorded for troubled projects. Critical knowledge areas for this phase include scope (definition), time and cost (estimation and scheduling), and risk (identification).
Project Plan Is Missing or Is Only the Schedule
As part of the project documentation package, we usually ask to review the project plan. At times, what is submitted as a project plan is simply a schedule, either in “mpp” Microsoft Project file format or an Excel spreadsheet, or sometimes just a high level timeline. The other elements of a plan, such as change control, escalation, and communication plans, roles and responsibilities, assumptions and constraints, are not documented or agreed to, and may not have not been thought out. In many cases, even if the project manager has had appropriate training, the practice of project management is more concerned with developing and installing code per the schedule, rather than the overall project planning and context.
Requirements definition can be a daunting and time-consuming task, and is often frustrating as well, depending on the availability, interest, and skill-set of the clients. For these reasons, we sometimes see this task abandoned before it is properly completed. A critical step in the software development lifecycle, it is also the most frequent source of software development problems. For project managers, it represents the full scope agreement the project must support. There are several specific inadequacies we see in this step.
1. The user community is unidentified or uninvolved. Actually, there can be many variations of this issue, such as users focused on current work and unwilling or unable to devote the necessary time; users with limited experience or understanding of the true needs; users who have not bought into the project or don't feel it will impact them; or users who feel their input will be ignored. The team may lament “We can't engage the user” and then proceed to make assumptions in place of this input. Except in very simple or well-defined projects (e.g., system replacement), these assumptions will usually contain grievous errors and misunderstandings, and the needs for which the project was undertaken will not be met. If getting users involved is a problem, escalation or reevaluation is a better course.
Example: In one case, an entire system was built before it became evident that there were no users.
2. Requirements are incomplete, late, or informal. This is a common problem for troubled projects, and may involve more than one of these conditions. Left open to differing interpretations, the result is likely to be disappointing.
Example: One project was so committed to their schedule that they finally moved from requirements, which were long overdue, to design, leaving requirements unfinished. While this had the appearance of meeting the schedule and moving forward, they ended up completing the requirements concurrent with both design and coding, resulting in continual churn to development activities.
3. Overlooked or missing requirement pieces. Projects can experience unfortunate surprises late in the development cycle when they realize they did not include some critical aspect of requirements. Most commonly neglected of these aspects are the requirements for migration, performance (e.g., response, availability, reliability), security, and user training.
Example: We found that requirements had been “baselined” on a project despite several significant known gaps left to be defined at a later date. However, if a true baseline is not fully defined, it becomes impossible to track the changes to this baseline, rendering the “baseline” meaningless, which is what happened here.
4. Insufficient detail. It is sometimes difficult to ensure enough detail is included without over-specifying. However, we do see cases where requirements get continually revisited, with many clarifications causing changes to design or development. In these cases, it is clear that the original understanding was at too high a level. When this is the case, it is often evident from a quick review of requirement documentation.
Example: We ran across one project team diving into implementation, convinced they knew how to handle the business problem. When they finally understood the implications of the real needs, there were many significant design changes necessary to support these, and new subprojects had to be undertaken as a workaround.
5. COTS system assumed to “replace” this step. It is especially important when a COTS system is involved to have well-defined requirements for a critical evaluation of the needs match. This may be left undone until late in the process when users or developers realize the product is not all they had envisioned.
Schedules are a sore point for software development projects, which are well known for not meeting due dates, and we found much the same story. Following are some of the major reasons we found for this.
1. Task estimates are optimistic or based on a given template. This is a common problem, as most software project managers know. It is easy for a project manager or the team itself to succumb to wishful thinking or outside pressure, and commit to overly “aggressive” estimates. Sometimes a standard template is followed by an organization, with predetermined timeframes for activities such as design or testing. However, these may be inappropriate for the task at hand.
2. Baseline is missing milestones or dependencies for the critical path. Sometimes we find that the schedule, although baselined, has not included some critical task that impacts later activities. Without visibility of the importance or progress of this task, delays here can unexpectedly impact the project.
Example: One example of unrealistic schedules was a project where requirements completion was not included as a milestone or dependency for other steps. Although the requirements had not been completed, the project proceeded according to schedule with design, only to return to requirements definition at a later time.
3. Schedule is high-level only, with no WBS (Work Breakdown Structure) or lover level task roll-up. A common misperception in scheduling is that when a predetermined target date is given, the schedule must be worked backwards in order to assure meeting the date. While this method is a useful step in determining the top-down approach, it is important to construct a bottom-up realistic estimate regardless of the target date. This is then worked in conjunction with a top-down estimate to negotiate alternatives, scope reduction, schedule compression, and other possibilities to arrive at a feasible and mutually acceptable schedule. Often a target high-level schedule cannot be realistically followed.
Example: Although a detailed bottom-up schedule had indeed been developed for one specific project, this was rejected when it did not meet the “need” date. A high-level milestone timeline was then created to accommodate management expectations with no means to fulfill this. Negotiations were not successful in resolving the schedule issues, and the project decided to forge ahead anyway, in effect keeping two sets of books—one for public consumption, and a detailed plan for actual project work. Before long, the working schedule could not be reconciled with the public milestones, and was shelved, leaving the project team struggling to somehow make the milestone dates. Not surprisingly, the project ran into trouble, and management was later forced to announce a delay.
4. Tasks unrecognized or not included. When requirements issues include overlooked items (as noted above) the schedule is usually impacted, as time has not been allocated for these items. In some cases activities not specifically related to requirements, such as planning or negotiation, are not included in the schedule, but do require some time. Either way, the resulting schedule does not reflect reality as not all work is represented.
The Real Risks Are Not Acknowledged
While technical risks such as third party software or external dependencies are usually noted, sometimes the risks that truly threaten the success of the project, although known to the team, have not been formally documented or acknowledged. These can include the impact of environmental issues like unclear or unstable requirements, lack of project manager authority, conflicting organizational goals, limited or inexperienced resources, and more. Very likely the teams are reluctant to bring these issues up, for fear of appearing to “whine,” and not expecting any leeway to address them anyway. But these are very real risks, and they must be acknowledged by stakeholders and assigned ownership.
The execution phase is where the detail design, development, and implementation take place, and the area many software development organizations are most comfortable. Accordingly we find somewhat less incidence of project management problems here. Problematic knowledge areas here include the management of resources, communication, and quality, as well as in setting priorities for these areas. Where applicable, vendor management is also key.
Communication and Information Flow is Limited
With respect to team communication, we sometimes see differing views among team members of what issues are open and what the priorities are, indicating a lack of consistent and timely communication, and infrequently some hostility among members. More often though, it is communication with clients and management that is inadequate or overlooked. Usually the problem is with infrequent updates or lack of full disclosure on information released.
Little Focus or Expertise in Vendor Management
We have found that due diligence is sometimes not done properly when considering vendor products or services. Contracts are too weak, and the project is left with insufficient leverage or ineffective performance constraints. This area has had little attention in organizations unaccustomed to the increased level of vendor use now seen, and more training and awareness is helpful.
Examples: One project having difficulties with a vendor product revealed that they had paid for the product before fully testing it, thereby forfeiting the leverage they had. Another project we worked with was hit with vendor schedule delays, but was low on the vendor's priority list, and had no contract clause to stir responsive action.
This is an area with several types of problems, discussed below. Nearly every project would like more skilled staff, but for some, resource issues are a significant problem, particularly with new technology.
1. Churn. Project teams often have difficulties maintaining focus and direction if key members change often, especially with shifting priorities. Large losses or additions also sap energy and focus, and morale.
Example: In an extreme case of resource churn, one project we looked at had had a total of 14 management-level changes (director, division, and district) within one and a half years—25 people in and out of 11 slots.
2. Lack of expertise and experience. Projects do not always factor these elements into the schedule, but they both require a longer learning curve, and this must be reflected.
3. Insufficient staffing. This is not always as straightforward as vacancies left unfilled; we see projects practicing a form of “double booking” with key staff members, e.g., being assigned (whether officially or not) to support both current production and the development of the next release. This often results in delays to the next release.
Process Violated (e.g., Quality Gates Ignored)
One way we determine what role process plays in a project is not only the documentation and claims made, but from interviews, where we discuss the specifics of how things are really done. We may find that Q-gates are forced through without the stated conditions being met, e.g., requirements definition, or test entry and exit criteria. Interestingly, we occasionally see too much process being used, where much time and money is spent on documentation of minutia, and unnecessary dedicated specialized positions are filled, for a small or simple effort.
Not Enough Attention to External Interfaces, Deployment, and Support
These areas may be overlooked during the implementation stage until they are needed. Items such as Service Level Agreements, production turnover documents, interfaces requiring accommodation, and preparation for OA&M (operations, administration and maintenance) may be left undone, and then get rushed or omitted, causing operational problems later.
Testing Interval Is Squeezed
With the issues discussed here occurring on any given project, delays often creep into the schedule. When the project does not adjust the schedule to account for these delays, a common tactic for meeting the end date is shortchanging the last scheduled tasks, usually testing. This may result in the testing being done in production, either as an intentional process or by default. This often produces a product of poor quality, and sometimes late as well.
Example: The project manager of one team we saw with this problem admitted “We get it out and fix it later.”
This applies to feature inclusion and change requests as well as issue resolution. We see projects that may prioritize change requests, for example with an automated tool, or use some criticality notation on a feature or issues list. However, some projects do not prioritize one or more of these. When prioritization is done, it is not always approached properly; we have seen decisions being made based on the developers’ preference, or the political clout of the requestor, rather than being filtered by true business needs. And some projects simply implement any change that is requested, without requiring validation. Conflicting objectives on a project may also lead to confusion in priorities, adversely impacting project progress.
Example: One project had three directors setting differing priorities for the team: new feature delivery, user productivity, and development efficiency. Another project had one director but multiple unprioritized and competing objectives: standardization for ease of future change, accommodation to unique interfacing systems, and an aggressive production rollout schedule. Both suffered from lack of direction and inability to achieve expected results. Then there was the project team that took exception to our finding that they did not prioritize issues, insisting that their list of over 100 issues all had priorities assigned—but every one was a priority 1!
Project Control and Tracking
Control and tracking is an area to which many of the problems seen can be attributed—we will look at control and tracking, as well as “status” reporting. Key knowledge areas needed in this phase are scope management, for the inevitable changes, communication, time and cost, to monitor and keep these in check, and risk management, particularly mitigation.
Tracking But No Control
There is a critical difference between these functions, and both are important. At times we see project managers performing only the tracking role, without ability and/or authority to truly manage project activities or results. Factors indicating a lack of true control include the following.
1. Ineffective issue resolution. This becomes a passive role of assigning and tracking action items and responses, without actively ensuring accountability or resolution.
2. Scope/requirements change management vs. change control. Again, this often looks more like a tracking and documentation exercise than a careful control of changes undertaken, filtered by business need and cost/benefit.
Example: With regard to change control, a few projects we looked at did not distinguish between change requests and fixes, precluding any real possibility of controlling change, inviting scope creep.
3. Escalation not invoked. Sometimes an issue is ignored until it becomes the crisis of the day. There can be a reluctance to “admit” needing management assistance to obtain closure on issues. However, clear escalation procedures can keep a project from stalling or making major missteps.
4. Unclear risk thresholds to trigger contingency plans. Some projects do a risk assessment, and may even have contingencies laid out, but do not have specific triggers being defined or used. So, the contingency plan does not kick in when it should, or it may be executed before there is an actual need. This is sometimes a result of difficulties in accurate tracking, in order to identify when the appropriate time comes.
Ineffective Progress Monitoring
Though control may sometimes be lacking, tracking is almost always accomplished to some extent. Any problems occurring here are related to the poor quality of monitoring done, leaving the true project status largely unknown.
1. Schedule not detailed enough.We have seen that without detailed project schedules, it is difficult to track exactly where a project is, or whether it is in trouble, until it hits (or misses) a major milestone. On the other hand, a project schedule may be too detailed.
Example: A project was attempting to maintain a very detailed schedule, with over 100 pages of Microsoft Project data, and update this weekly. Because the updates took more than a week to compile, the schedule was never accurately completed, and it became obsolete.
2. Use of % complete to track status. This is commonly referred to as the 80% syndrome. Without more explicit measures of completion, tasks may quickly reach a reported 80% completion, and stay there indefinitely.
3. Schedule updates not made. These projects develop an original schedule, but do not revisit it either to reflect changes or revisions made to planned tasks or dates, or to update the planned completion dates with actuals.
Example: This project had a particular critical task assigned to someone who was out for an extended period. Although the task had not been completed, this was not recorded or noticed until a later task became held up.
4. Milestones not tracked back to original schedule.Related to the previous point, these projects have an original schedule, but when changes to scope and/or target dates are made, actual completion of milestones is measured against the dates on the latest timeline, and never evaluated against what was originally planned as a baseline.
Example: One project went through a series of “small” two-week delays without fully reevaluating the schedule—and ended up with a cumulative six-month delay.
5. Schedules not integrated across the program or project. This can occur when projects within a program have separate project managers, inadequate communication, and no overall program manager. Critical dependencies are missed, and dates and/or tasks are not in sync for work requiring impact to multiple projects.
Example: One project schedule included both target (desired) completion dates and committed dates, for differing subprojects—but did not distinguish between representing these. As a result, there was no way to tell if a late actual completion date represented a true problem or not.
Status Reporting Is Misleading or Infrequent
Intimidation or fear sometimes leads project managers to follow the “no bad news” policy of reporting. For example, when schedules become tight, projects may adjust the scope down, but not officially report this, even though the team is well aware of the change. Or, delays may be kept quiet until the last possible moment. Not owning up to problems early only makes customers and management more upset, since there are fewer options available to deal with the situation once they do know, and they may well have made promises or decisions based on bad or outdated information. Similarly, reporting information infrequently leaves stakeholders without critical knowledge or input.
Example: During interviews with one project, team members noted in confidence that they felt they were “not allowed” to report milestones in “red,” or that they “would be crucified” if anyone knew they expressed less than 50% confidence in the due date being met.
The issues in the closeout phase are less obvious, and not as prevalent, but there are still some important points:
Success Not Evaluated (But May Be “Declared”!)
With completed projects, there is a tendency to celebrate, breathe a sigh of relief, and move on. In many cases, no one is anxious to look back at what was expected, and they simply see completion as all the success that is needed. But to determine true success, it is necessary to ensure that the results meet expectations.
1. Original objectives and/or success criteria missing. It is difficult to assess success if there is nothing definitive to compare against. And if the objectives are vague, success can easily be declared without contest.
2. Customer satisfaction feedback missing. Another factor in determining success is whether the customer is satisfied, which can be accomplished via feedback surveys or other methods. But although many projects track IT productivity metrics (using function points, etc.), they may lack customer satisfaction ratings and customer-affecting metrics such as performance and availability.
Project Is Not Closed—And Never Dies
There are some projects that continue to be funded even though they have run significantly late and over budget. If objectives for the project were unclear, or business case measures are not validated and tracked, it is difficult to know when a project is no longer viable, and some of these runaway projects should clearly have been closed.
Learnings Not Captured or Used for Subsequent Efforts
Sometimes when we go back to a project for a follow-up or related review, we may end up with very similar results, indicating that lessons from earlier mistakes were not being corrected. And although projects often do “post-mortems” or sessions on “what went wrong and what went right,” the project practices do not always change. This is an important point, because once the process itself becomes the object of conscious improvement, any of these problems can be successfully dealt with. And without this, assessment findings may not help at all.
Some Good News
In spite of the many problems noted above, there have been some notable improvements in the way projects are managed at AT&T. We do take note of things that are done particularly well, and have identified the following based on general trends in the projects we assess.
1. More tools are used to facilitate project management, such as Microsoft Project or a similar tool, for scheduling and tracking (and increasingly for dependencies and resource assignments), automated change control tools, requirements repositories, and trouble tracking systems. Two caveats—these are only tools, and do not take the place of active project management. And, if they only add more work without real benefit, they are not helpful.
2. Websites are often used for project communication and keeping members up to date with versions and changes.
3. Alternatives such as diverse technology, COTS, scaling down, and phasing are considered and often used.
4. Many project plans clearly identify risks, mitigation plans, goals/objectives, scope, status, issues, and the like.
5. Communication lines with users are much more open, with greater understanding of the business, and a greater sense of urgency.
6. There is increased responsiveness to changes in business direction and priorities.
7. More projects have identified project manager positions, with more project managers being trained.
8. Process definition has become common, with more proper execution of the process as well.
9. Team members are very dedicated and work well together, pitching in when necessary to get the job done.
Project Management Challenges
The improvements described above are truly promising, but project management is also getting tougher. This section describes some of the trends we are seeing in the types of projects being undertaken, and the challenges these present for project management, beyond the difficulties already evident. These are organized by the project management knowledge area most critical to meeting these challenges.
Vendor Management: Projects are using more COTS (Commercial off the shelf) systems, and entering into more vendor partnerships. The challenges this presents are a need for more contract sophistication, adjustment of SW processes to accommodate the use of COTS, and the development of a framework for customization guidelines.
Integration Management: Trends here are toward bigger projects, with increased cross-organizational spans. This creates challenges such as more cross-organizational conflict, and an even greater need for a clear project manager with authority and in some cases an overall project or program manager. Extended multifunctional teams are key.
Scope Management: There is increasing business complexity in projects, requiring better problem definition. This means the ability to answer the basic question of what business problem you are trying to solve.
Resource Management: Downsizing, outsourcing, resource churn and shortfalls are all becoming common across the industry. Managing with a staff having lower skills or experience levels are a consequence, requiring longer learning curves, more training, mentoring, orientation, and documentation, and creative resource sharing such as “on-loans.”
Time/Cost Management: With shorter time-to-market and budget cuts becoming the norm, project managers must deal with increasingly tighter schedules and strained resources. Realistic estimates and scope are critical.
Risk Management: Taking on increased risk in projects has become necessary in this dynamic environment, requiring careful monitoring of situations, and more thorough contingency planning. The area of risk management has attracted much more attention recently, and project managers should ensure they are proactive in this area.
Quality Management: More and more, the definition of quality on any given project is getting scrutinized, resulting in variable levels of quality required depending on the costs and needs. Project managers will be challenged to optimize the cost/benefit, and will need to customize the quality process used accordingly. It is not always necessary to provide five-nines availability, realtime data, disaster recovery, or the newest and best technology.
Communication Management: We are seeing more public and external commitments being made for capabilities and services specifically supported by IT projects, and more organizational complexity within these. This will require expertise in communicating with full disclosure and timely escalation of any jeopardy situations, and will require availability of real-time, dynamic information.
Critical Success Factors
In light of the many difficulties we see projects continuing to face, we have developed a “top 10” list of elements we find to be particularly effective in starting and keeping a project on track for success. These are offered below.
1. Empower the project manager with true accountability and authority. If the “project manager” is really a facilitator, ensure there is someone else (perhaps a higher level) clearly owning the true role.
2. Define the problem and success criteria in clear and measurable terms.
3. Document the scope and just as important—the boundaries of the scope.
4. Get both functional and operational requirements clarified—they are both important.
5. Plan any COTS use carefully, and match the product to the needs.
6. Use and update the schedule—it is there for project control.
7. Estimate workloads realistically—this is not a question of how good the estimate looks, but how good it is.
8. Acknowledge all project risks—this includes the sensitive or politically incorrect issues.
9. Include all tasks, including planning, in the WBS and schedule—check all inputs to verify full coverage.
10. Communicate frequently and honestly—hiding a problem almost always makes it worse.
With increased attention to these factors, software projects can continue to improve in both process and results, and help reverse the lowered expectations IT has engendered in many circles. Though we often hear that many of the issues are not under the control of the project manager, we also see from successes that the project manager's sphere of influence is usually underestimated. Simply speaking up, and getting formal acknowledgement from management or customers of the risks or costs that a situation “not in your control” presents, often provides the impetus needed for the situation to be addressed. A final note—the pitfalls and challenges presented here are problems the project manager must address. These are not issues of rhetoric or futility, and they are not someone else's responsibility to fix. They are your struggles—and yours to overcome.
Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA