Application development projects fail for a myriad of reasons; most, however, stem from poor project management. This article describes a practiced guide for analyzing projects from the Initiation phase to close-out. Performed correctly, the guide increases the chances of project success em well as gives an organization an opportunity to develop project management skills.
THE LONG-TERM VIABILITY OF ANY IT organization is dependent upon the success of its systems development activities. New development projects hold the promise of expanding services and increasing the productivity and efficiency of established work processes. Yet, few development projects deliver on this potential, instead falling victim to any of a collection of pitfalls. Project managers are all too familiar with technological or business evolution that renders the project obsolete before its completion, project escalation and costs that spiral out of control, and deterioration of communication among system designers and developers. Furthermore, as the complexity and importance of applications increase, the implications of failed development efforts are magnified. An effective project management process, therefore, is critical to the successful completion of development work.
Project assessments are an essential component of the project management process that often are forgone or neglected. Performed regularly, assessments foster early problem detection and correction by enhancing feedback and generating continuous improvement in the project management process. The benefits of project assessments are significant and include
· maintaining open communication between project team members and stakeholders
· protecting the investment of the organization by promoting more thorough planning, thereby improving performance and identifying problems before they threaten project success
· encouraging the project manager to maintain and produce timely records and reports, providing an appropriately ordered and controlled development environment
· detecting ineffective management activities or practices that often are invisible when regularly scheduled reviews are not undertaken
· applying evaluative information gleaned from assessments toward continuously improving the systems development methods and execution on future projects
· providing a mechanism by which team members may voice their concerns and observations regarding the project or methodology
· providing a training and learning opportunity for current and prospective project managers as they participate as members of review teams
As with all control processes, the breadth and depth of project assessments should be commensurate with the risk associated with the project.
THE PROJECT ASSESSMENT PROCESS
The guidelines presented herein are based upon the Project Management Body of Knowledge published by the Project Management Institute. The PMBOK (pronounced "pim-bok") identifies and describes the generally accepted and proven practices associated with project management. These practices are grouped into nine categories referred to as knowledge areas, each with associated subprocesses: integration, scope, time, cost, quality, human resources, communication, risk, and procurement management. The subprocesses are executed over time, with the output of one subprocess serving as input to another. The result is a chronological progression through a series of related activities, each with associated tools, techniques, and practices.
Project assessments are undertaken within the context of these activities as they unfold over time, typically grouped into five overarching processes: initiation, planning, execution, control and close-out (Exhibit 1). Iteration frequently occurs between project execution and planning as actual project work proves some aspect of the project plans intractable. Iteration also occurs between the project control and close-out procedures when it is determined that all project deliverables have yet to be met satisfactorily. Three of these processes (planning, control, and close-out) can be decomposed further into a collection of subprocesses, referred to as core processes within the PMBOK. As depicted in Exhibit 1, all five overarching processes necessarily rely upon a set of facilitating processes.
INITIAL ASSESSMENTS
Once begun, systems development projects can prove extremely difficult to abandon. It is imperative then that a clear scope be defined for development projects. Early project assessment, therefore, is essential. The purpose of the initial project assessment is to assure management that each new project is feasible, has a viable plan, and has achievable targets. The initial assessment
· provides an assurance that the project is starting with defined objectives and goals
· determines whether project plans are complete, defining all deliverables as well as tasks and needed resources to develop those deliverables
· establishes a discipline for the project manager, requiring an overall demonstration of effective planning
This assessment establishes an initial project baseline against which future changes in project scope or system functionality can be gauged.
The initial assessment provides an evaluation of the deliverables associated with the project initiation and project planning processes (Exhibit 2). Deliverables for these processes include the product description, project charter, constraints and assumptions, statement of scope, work allocation structure, project work plan, and supporting detail information. Project reviewers should concern themselves with several issues during this assessment:
· Structure: Is the project team structure compatible with the organization type (functional, weak matrix, balanced matrix, strong matrix, or projectized)? Is the project manager's authority and role consistent with the team structure?
· Project scope: Does the project support the strategic plan of the organization? Is the project scope specific m defining what is included m and excluded from the project?
· Project deliverables, objectives and completion criteria: Is there a natural progression between the business need or other impetus for which the project was begun, the objectives of the project, the product description, project deliverables, and work allocation structure? Are these thoroughly specified? Are the completion criteria specific and acceptable to all stakeholders, particularly to the sponsor, the client, and IT operations?
· Feasibility: Is the project technically, operationally, and financially feasible? How reasonable is the project schedule?
· Assumptions and constraints: Are assumptions and constraints written and communicated to all stakeholders? Do the stakeholders understand the inherent risk associated with each?
· Time, cost and quality estimates: Are time, cost, and quality estimates realistic? Are these estimates acceptable to stakeholders?
· Client and project team responsibilities: Are client and team responsibilities well defined? Have they been communicated to stakeholders, and do the stakeholders support them?
PROGRESS ASSESSMENTS
Progress assessments are performed at predetermined intervals during the execution of the project. Assessment intervals depend upon (1) the size of the project, (2) the duration of the project, (3) the phase of the project, (4) risk assessment outcomes, ($) project team experience, (6) the level of participation by the project manager, and (7) project manager experience. A critical element of success in conducting progress assessments is knowing what to assess and what problems to anticipate m the project. Only then can problems be addressed early, prior to impacting severely the project effort. Progress assessments focus upon the deliverables in the execution and control processes (Exhibit 2).
Progress assessments focus on comparing actual versus planned activities and outcomes in an effort to identify deviations that may indicate a project in trouble. Deviations, however, only signal potential problems. Project reviewers then must identify the root cause of any deviations and determine the size and potential impact of the problems. Additionally, gauging the criticality of the problem, the project manager must prescribe an action plan to address the deviations. Deviations may evolve in several project areas:
· Project plans: Do the project plans define what must occur to allow the project to achieve its predetermined objectives? If plans are inadequate, they are likely to misdirect the project. A series of related issues must be addressed:
--Do the plans exist? Plans must be in written form and conform to standards.
--Are the plans complete, consistent, and practical? Are there review, rework, and approval tasks? Are there tasks for external dependencies such as hardware and software delivery and installation? Are tasks defined in detail, with each task having completion criteria and a detailed description?
-- Are the work plans working documents? Look for indications that the plans are used to execute and control the project.
· Change control: Are change control procedures being used? Is the final disposition of a change request communicated to the project team within an appropriate time frame? Does the original work plan include time for investigating project change requests? Is time spent investigating project change requests being reported and recorded? Is change activity consistently reported to management? Are change decisions being made within an appropriate time frame? Are approved changes reflected in the documentation, training, and other implementation processes? If so, how? Have there been too many changes? If so, why?
· Products: Do all work products have quality assurance checks to ensure that the products conform to approved format, content, level of detail, and quality? Do the products reflect the current baseline?
· Client participation: Does the client share accountability for the success or failure of the project? Are client obligations being fulfilled? Is the user approving deliverables? Are approvals performed in an appropriate time frame?
· Development environment: Is the current environment undergoing any significant changes? Have new environmental design constraints been imposed late in the project? Are operation and change management procedures reflected in the schedule?
· Resources: Is project staffing adequate? Are the skills of the project team being used effectively? Is the project manager's span of control too narrow or too broad? Are the contributions of part-time project team members acceptable? Are people continually being added to the project team? Is there a high turnover rate on the project team? Have any key team members been replaced and, if so, what is the impact on the schedule? Is overtime being tracked by the project manager? Is overtime excessive? Has overtime become a ready solution to the underestimation of time required to perform project-related work? Has the efficiency of overtime been demonstrated? How is it measured? Is overtime work contributing to morale problems?
· Communications: Is communication with all stakeholders being performed in a timely manner? Are important decisions and approvals being documented? Is an audit trail available? Are there open communication channels between the sponsor, clients, and project team? Are status-reporting methods and formats consistent, or are new performance measures frequently introduced? Do progress reports contain quantitative measures? Do team members submit written status reports consistently? Is the project manager completing status reports consistently, and are they consistent with the team member reports?
· Morale: What are the stakeholders' perceptions of the project manager? Does there appear to be a personality conflict between any of the project team members? Does there appear to be a conflict between project team members and clients? Are there constant changes in project direction?
· Lessons learned: Is new knowledge being accumulated in an organized manner as the project progresses? Common practice is for such knowledge to be considered at the conclusion of the project when typically it is too vague and removed from the actual experience from which it arose to be of significant value.
· Assumptions and constraints: Are the assumptions and constraints elucidated at the outset of the project still valid? Is there a formal means of updating assumptions and constraints and communicating these changes to all stakeholders?
· Project scope: Is the scope of the project still consistent with the strategic plan of the organization? Has the scope of the project been creeping unchecked? If so, are mechanisms available to halt this trend?
· Time, cost, and quality: [lave time, cost, and quality estimates proven reliable? If not, what is the cause of their inaccuracy? Are time spent, costs, and quality within acceptable limits?
· Relationship management: Are vendors, outsourcers, and contractors meeting their commitments relative to the project? Is the project manager providing to outside constituents the necessary information to allow them to perform adequately their responsibilities?
PROJECT COMPLETION ASSESSMENTS
Project completion assessments are used to determine whether project objectives were met through the completion and implementation of project deliverables. It further verifies that contractor obligations were met and formal acceptance of the project was secured. The assessment provides a particularly rich composition of historical reformation that can benefit future projects. This assessment can complement, but is not a replacement for, the postinstallation review. The assessment should evaluate planned versus actual outcomes for the project and should determine
· the extent to which the envisioned benefits of the project were realized
· the extent to which budgeted costs were met for the individual phases of the project and the overall project
· the extent to which the project met its specified schedule and milestones
· the extent to which the project met specified quality standards
Consistent with the use of historical information in the PMBOK, this information contributes to a historical knowledge base from which are gleaned valuable lessons to be applied to future project management efforts. In this manner, the project management process is improved continually.
ASSESSMENT RESULTS
Preliminary findings resulting from any of the three project assessments are brought before the project manager for review and consideration. Performed correctly, the project manager is made to feel involved in the articulation of the findings and recommendations emerging from the review. The project manager then should use the assessment findings to develop a detailed action plan.
Naturally, the project manager may not agree completely with the findings and conclusions of the assessment, the severity rating assigned to problems, or final recommendations; reasonable differences of opinion will occur. Working toward an agreement that will prove acceptable to all stakeholders, both reviewers and the project manager therefore should be granted an opportunity to present to upper management their opinions, concerns, and suggestions.
Following resolution of conflicts within a prespecified period of time (typically within one week), the project manager should develop an action plan. Quick response times are important to preserve project momentum. The action plan should address systematically each problem identified in the project assessment. In addition, the action plan should identify required resources and specify a schedule for resolving the problems. This plan then is folded into the revised and realistic overall project work plan. Problems and progress toward their resolution then should be tracked and reported upon within management status reports until resolved.
CONCLUSION
Project failure usually results from a breakdown in the project management process. Project assessments can provide an objective evaluation of a project by
1. assisting the project manager in recognizing and confronting existing or potential problems
2. suggesting appropriate solutions
3. providing management with sufficient information to take early corrective action, if required
4. offering a mechanism for continuing communication between and amongst senior and information technology management
To be successful, however, project assessments are dependent upon several factors. First, the organization must have instituted a formalized project management process. Assessments require a benchmark of deliverables and processes such as that offered by the PMBOK. Second, the intent of the assessment must be to assist the project manager rather than critiquing that manager. Project assessments can be an important vehicle for learning, providing necessary support to project managers as they develop their skills. Third, project assessment team members must have the appropriate skills and characteristics. Team members must possess an in-depth understanding of the project management process and application development. Team members also should be mature and experienced, with the ability to analyze problems objectively and quickly, identifying important underlying trends.
The complexity, capriciousness, and conceptual nature of systems development projects point to the need for a systematic approach to such efforts. For many organizations, formal project management is the strategy of choice. Often, however, project management fosters conflict. Senior management wants detailed planning and progress reporting on projects. Conversely, project teams often view time spent on formal project management activities as time wasted -- time better spent performing the countless tasks associated with the project itself. Project assessments can bridge this void effectively. They provide requisite feedback to upper managers and project managers while simultaneously enhancing the efforts of project team members. A
DIAGRAM: EXHIBIT 1; Project Assessments
Legend for Chart:
A - Process
B - Deliverables
A
B
Initiate and Plan
Project charter
A description of the management approach
to be used
Scope statement that defines the project
deliverables and project objectives
Work breakdown structure decomposed to the
appropriate level of control
Cost estimates
Work plans defining task start and finish
dates and responsible resources
Baselines for cost and schedule
Major milestones
Key staff
Key risks including constraints and assumptions
Open issues and pending decisions
Execution and Control
Work results -- deliverables that have been
completed fully or partially
Product documentation developed to describe
the project's deliverables
Approvals verifying acceptance of project
products
Rework of defective deliverables
Completed checklists used to assure quality
Performance appraisals
Performance or status reports organizaing
and summarizing project progress
Change requests and change request log
Proposals and contracts defining seller's
ability to provide the requested product
Close-out
Project archives
Formal acceptance
Lessons learned
Contract file
Recommended Reading
1. Keil, M., Pulling the plug: Software project management and the problem of project escalation, MIS Quarterly, 19, 421, 1995.
2. Pinto, J. and Slevin, D., Critical success factors in successful project implementation, IEEE Transactions on Engineering Management, 34, 22, 1987.
3. Duncan, W.R., A Guide to the Project Management Body of Knowledge, Project Management Institute, Upper Darby, PA, 1996.
~~~~~~~~
By Russell L. Purvis and Gordon E. McCray
RUSSELL L. PURVIS is an assistant professor of management information systems at the University of Central Florida, Orlando
GORDON E. MCCRAY is an assistant professor of information systems and technology at Wake Forest University, Winston-Salem, NC.
Copyright of Information Systems Management is the property of Auerbach Publications Inc. and its content may not be copied without the copyright holder's express written permission except for the print or download capabilities of the retrieval software used for access. This content is intended solely for the use of the individual user.
Source: Information Systems Management, Winter99, Vol. 16 Issue 1, p55, 6p, 1 diagram.
Item Number: 1394172