Project Planning & Procurement
Implementing Projects
- Check the Status of My Project
- Project Lifecycle
- Initiation
- Planning & Procurement
- Implementation
- Close Out
The Project Plan is a document explaining the high level details of the proposed project. Key stakeholders of the project are heavily involved in the process of developing the Project Plan. The building of the Project Plan helps the Project Manager solicit information from the team and the vendor concerning the issue at hand and the possible solutions. Feature requirement lists are created, demonstrations are scheduled to find a solution that fits the needs of the team, cost estimates are bundled together, scope and assumptions are defined, risks are noted, and a preliminary timeline is built. This phase may also include a “proof of concept” where test environment(s) are acquired and set up to determine which particular product or package will work best within the confines of our environment. Once a product has been selected to solve the business issue, the Project Plan document can be completed with the scope, cost, and timeline of the project. All relevant stakeholders should have had input into the document and by this point in time, we should be within ±10% concerning Time, Scope and Cost of the implementation of this project. The Project Plan should also include a Communication Plan, resource responsibility matrix Risk Management Plan, HR Plan, and a Change Management Plan.
Once the Project Plan has been signed by the team, the Project Manager, and the IT Director directly affected by the implementation of the project, the Executive Project Summary document can be sent to the appropriate approver(s). The signing of the Executive Project Summary signifies that the project has been approved for procurement and implementation and the Project Charter can then be sent out.
As with any planning document, the Project Plan is a living document and will be updated periodically as the project progresses. The deliverable from the Project Plan is the Project Work Breakdown Structure.
The Project Charter is the document that announces the start of a project and the resources who will be working on the project. The Project Charter is sent to all relevant stakeholders asking for their cooperation in the project.
Procurement
The procurement process begins with the securing of funds during the Business Justification process. Once a project has been approved, the contract from the vendor can be routed through the Contract Routing process.
Triple Constraint Triangle
The grid below prioritizes the critical project dimensions and is used to negotiate changes during the course of the project. The first step is to specify the constraining dimension. Is the critical project driver scope, cost, quality, or time? The second step is to specify the dimension that could accept change. If change is required, in which area are the key stakeholders most willing to accept change: scope, cost, schedule, or quality? Change must be accepted in at least one dimension. This is specified in the Vary column below. Remaining dimensions are then minimized or maximized. These dimensions will be utilized for all aspects of the project, unless explicitly stated in a sub-project definition.
A balance exists between the four project dimensions and a change in one will impact the other dimensions. For example, if the scope dimension increases then the schedule and cost dimensions will also increase to maintain the quality dimension. If the scope dimension increases, but schedule and cost stay the same then the quality dimension may decrease.
The project dimensions are specified below, with Constrain in at least one dimension and vary in at least one dimension:
|
Project Dimension |
Minimize/Maximize |
Constrain |
Vary |
|
Scope |
|
X |
|
|
Cost |
Minimize |
X |
|
|
Schedule |
Minimize |
|
X |
|
Quality |
|
X |
|
One way to read the dimension grid above would be to say the following:
Delay in implementing the proposed solution will have a negative ripple effect on our ability to meet strategic goals to improve our operational efficiencies as well as customer service goals. There are also primary windows of opportunity for implementation that fall between major processes where in implementation workload is more effectively managed. The goal would be to time implementation so that students will most immediately notice the positive changes. Preferred implementation “go live” goals would be for Fall assignments process or Spring semester opening. We are targeting the Fall Assignments process.
Temporary help or temporary reassignment of current staff may be required to manage work load leading up to implementation milestones.
Scope
Scope Planning: Creating a project scope management plan that documents how the project scope will be defined, verified, controlled, and how the work breakdown structure (WBS) will be created and defined.
The scope of the project includes the Vision, Mission, Background, major project activities for each phase of the project, planned process improvements, and out of scope activities critical to the success of the project.
Primary objectives (critical success factors) are also included within the scope of the project. The success of the project is measured against the attainment of the project objectives. As such, they must be measurable and have associated project success criteria.
The key benefits to ASU in achieving the objectives is also included within the Scope of the Project.
Planned Process Improvements: All current and future business processes will be documented and reviewed. The Implementation Team will be focused on outcomes rather than current inputs or existing processes. The goal will be to implement the “Best Practices” contained in the (Software being implemented without modification. ASU Departments will adjust business processes as reasonably required to conform to best practices. Any exceptions will require the approval of the Angelo State University Project Sponsor.
The term “Best Practices” refers to the processes that are built into the software. By selecting the software system, ASU is adopting these “Best Practice” processes to replace their existing processes. Although some changes to the software processes may be required in unique circumstances, failure to limit these changes could impact the overall success of the project.
Assumptions concerning Resources, Priorities, Legacy Systems and Processes, Governance, Access, Training, Data Migration, Testing, Modifications to the system are also identified within the scope planning of the project definition document
Scope Verification: The project team will be required to sign the PPD before project implementation can begin. This signifies the teams’ formal acceptance of the planned project deliverables.
Scope Control: Many projects fail to come in on time, with this budget and cost due to scope. Scope is the adding of features and functions without addressing the effects on the time, costs, and resources, or without customer approval, any change to the scope during the implementation that will affect time, cost or scope will be required to be approved through the change management process.
Work Breakdown Structure
A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents and increasingly detailed definition of the project work. The Work Breakdown Structure is decomposed into work packages. The deliverable orientation of the hierarchy includes both internal and external deliverables.
The Work Breakdown Structure is then built based upon activities required to complete the project. Some of the more common are as follows:
- Purchase Software
- Purchase Hardware
- Install Hardware
- Install Software
- Business Process Analysis
- Attend Training
- Process Set up
- Test Processes
- Interface Set up
- Test Processes
- Data Conversion
- Test Processes
- Set Up Security
- Test Reporting
- Planned Communication
- Update BPAs and Document New Processes
- Train End Users
- Move to Production
- Project CloseOut
Cost
Within the PDD, an overall project budget is presented and denotes where funding for both the implementation of the project and ongoing maintenance will be derived from. A contingency fund of 10% of the total project implementation cost is always listed within the budget. The document defines who the Budget will be monitored and managed by, and who billing questions related to the project and invoices will be communicated directly to. (input sample budget here)
Timeline
Project Time Management includes the processes required to accomplish timely completion of the project.
- Activity Definition
- Activity Sequencing
- Activity Resource Estimating
- Activity Duration Estimating
- Schedule Development
- Schedule Control
The WBS is used to create the Timeline for the project. The processes used to create the timeline are as follows:
Activity Definition - Identifying the specific schedule activities that need to be performed to produce the various project deliverables.
- Purchase Software
- Purchase Hardware
- Install Hardware
- Install Software
- Project Kickoff Meeting
- Set Training Dates
- Attend Training
- Configure Software
- Test Configuration
Activity Sequencing - Identifying and documenting dependencies among schedule activities.
- Purchase Software
- Purchase Hardware
- Install Hardware. Dependent on B.
- Install Software. Dependent on A, B, C.
- Project Kickoff Meeting
- Set Training Dates. Dependent on E.
- Attend Training. Dependent on A, B, C, D, E, F.
- Configure Software. Dependent on A, B, C, D, G.
- Test Configuration. Dependent on A, B, C, D, G, H.
Precedence Diagram Method
Based upon the activity sequencing above, one could diagram the activities as such:
Activity Resource Estimating - Estimating the type and quantities of resources required to perform each schedule activity.
| Activity | Dependencies | Resources | |
| A | Purchase Software | Project Office | |
| B |
Purchase Hardware |
Project Office/IT | |
| C | Install Hardware | B | IT |
| D | Install Software | A, B, C | IT |
| E | Project Kickoff Meeting | Project Team | |
| F | Set Training Dates | E | PM/Project Team |
| G | Attend Training | A, B, C, D, E, F | Project Team |
| H | Configure Software | A, B, C, D, G | |
| I | Test Configuration | A, B, C, D, G, H |
Activity Duration Estimating - Estimating the number of work periods that will be needed to complete individual schedule activities.
| Activities | Dependencies | Resources | Duration Best Case in Days | Duration Most Likely in Days | Duration Worst Case in Days | |
| A | Purchase Software | Project Office | 10 | 20 | 40 | |
| B |
Purchase Hardware |
Project Office/IT | 5 | 10 | 30 | |
| C | Install Hardware | B | IT | 1 | 1 | 7 |
| D | Install Software | A, B, C | IT | 1 | 2 | 3 |
| E | Project Kickoff Meeting | Project Team | 1 | 1 | 1 | |
| F | Set Training Dates | E | PM/Project Team | 3 | 5 | 8 |
| G | Attend Training | A, B, C, D, E, F | Project Team | 3 | 3 | 3 |
| H | Configure Software | A, B, C, D, G | 10 | 20 | 35 | |
| I | Test Configuration | A, B, C, D, G, H | 20 | 30 | 60 |
Using the PERT Estimate, we can get a more precise calculation of estimated activity duration
| Activities | Dependencies | Resources | Duration Best Case in Days | Duration Most Likely in Days | Duration Worst Case in Days | PERT Estimate | |
| A | Purchase Software | Project Office | 10 | 20 | 40 | 22 | |
| B |
Purchase Hardware |
Project Office/IT | 5 | 10 | 30 | 11 | |
| C | Install Hardware | B | IT | 1 | 1 | 7 | 2 |
| D | Install Software | A, B, C | IT | 1 | 2 | 3 | 2 |
| E | Project Kickoff Meeting | Project Team | 1 | 1 | 1 | 1 | |
| F | Set Training Dates | E | PM/Project Team | 3 | 5 | 8 | 5 |
| G | Attend Training | A, B, C, D, E, F | Project Team | 3 | 3 | 3 | 3 |
| H | Configure Software | A, B, C, D, G | 10 | 20 | 35 | 21 | |
| I | Test Configuration | A, B, C, D, G, H | 20 | 30 | 60 | 33 |
Critical Path Method
Now that we have duration estimates, we can find the critical path of the project. Meaning, the longest sequence of activities that has to occur for the project to complete on time. These are the activities that must stay on track.
A + C + D + H + I = 80 DAYS
B + C + D + H + I = 69 DAYS
B + C + D + G + H + I = 72 DAYS
E + F + G + H + I = 63 DAYS
The Critical Path is ACDHI. Meaning that these items are dependent upon each other and are in the critical path of this project being completed on time.
Schedule Development- Analyzing activity sequences, durations, resource requirements, and schedule constraints to create the project schedule.
Schedule Control- Controlling changes to the project schedule.
To determine the actual Due Dates for each of these Activities, the Project Manager will request that the project team update the BlackOut Calendar for this project. The Blackout Calendar shows dates that Team members will be unavailable to work on the project. Once this has been done, the PM will enter your project start date and then base each activity due date upon the PERT estimate for that task as well as activity dependencies.
| Activities | Dependencies | Resources | Activity Duration in Days | Start Date | Due Date | |
| Project Start Date | 3/2/2009 | |||||
| A | Purchase Software | Project Office | 22 | 3/2/2009 | 3/31/2009 | |
| B |
Purchase Hardware |
Project Office/IT | 11 | 3/2/2009 | 3/16/2009 | |
| C | Install Hardware | B | IT | 2 | 3/17/2009 | 3/18/2009 |
| D | Install Software | A, B, C | IT | 2 | 3/19/2009 | 3/20/2009 |
| E | Project Kickoff Meeting | Project Team | 1 | 3/2/2009 | 3/2/2009 | |
| F | Set Training Dates | E | PM/Project Team | 5 | 3/3/2009 | 3/9/2009 |
| G | Attend Training | A, B, C, D, E, F | Project Team | 3 | 3/23/2009 | 3/25/2009 |
| H | Configure Software | A, B, C, D, G | 21 | 3/26/2009 | 4/24/2009 | |
| I | Test Configuration | A, B, C, D, G, H | 33 | 4/27/2009 | 6/10/2009 |
Quality
As a project is undertaken to be implemented a standard for the level of quality will need to be set. Quality Assessment visits by consultants or by peers review may be initiated throughout the project to ensure the level of quality of both inputs and outputs are as they should be.
HR Plan
Included in the Project Definition Document (PDD) is the Human Resource Plan which includes a Stakeholder Analysis, Project Organization & Responsibility Matrix.
Project Organization & Responsibility Matrix
The organizational structure of each project will consist of staff from the vendor and staff from Angelo State University (ASU). Project governance will be provided by the Project Management Team from ASU.
The Project Implementation Team is composed of ASU personnel and the vendor’s Team. Work teams will be established as needed to perform specific activities for the project and are frequently cross functional. Members from those teams will be responsible for developing strategies for change for the University by formulating communication, training, and organizational readiness plans.
Team Member Qualifications
Team members are selected for, and must abide by, the following qualifications:
- Ability to make decisions by consensus.
- Ability to work well under pressure and in a professional manner.
- Detailed knowledge of their functional area.
- Ability to listen and value input from all participants.
- Committed to clear, shared goals.
- Ability to work as a team and to interact on a regular basis to accomplish specific tasks.
Executive Sponsor
The Executive Sponsor will work with the project management team, and third parties to expedite and resolve issues that require the highest executive level involvement, such as contract amendments. The Executive Sponsor will promote the visibility and credibility of the project.
Technology Steering Committee
The Steering Committee will be responsible for guiding the implementation from a Residence Life Office point of view. This will include making appropriate policy decisions when needed, and expediting decisions.
Project Management Team
The Project Management Team will manage all project related activities and tasks and is responsible, along with the Implementation Team (described below), for the successful project implementation. The Project Management Team is responsible for getting the work “done” – on time, within budget, and according to specifications.
In addition the Project Management Team is responsible for:
- Developing and maintaining project plans.
- Managing project scope.
- Coordinating activities for area teams.
- Ensuring adherence to project plans.
- Establishing the training schedule and monitoring the training library.
- Ensuring documentation is started and completed.
- Ensuring training is scheduled and available for project team members and end users.
- Ensuring that the Communication Plan is followed.
- Facilitating and negotiating resolution of critical communication and business processes.
- Ensuring the resolution of problems, issues and change requests.
- Leading the Project Team.
- Working cooperatively with area team leaders and all teams members.
Members of the Project Management Team are listed in the PDD
Departmental Implementation Team
The departmental Team is responsible for the following:
- Perform Business Process Analysis.
- Ensure that Best Practice processes are implemented.
- Define and test user procedures for their area.
- Develop Policy and Procedures Manuals and end-user training documents.
- Validate converted data in their area (if applicable).
- Attend training.
- Make decisions by consensus.
- Recommend policy changes or system changes to Project Management Team.
- Ensure completion of major tasks.
- Form functional work teams as needed and assign tasks and responsibilities.
- Provide status reports to Project Management Team.
- Define data fields that will be used by Residence Life Office.
- Set rules on the design/construction/inputting of data fields.
- Set standards for the communication and business processes to be used by Residence Life Office.
- Support proper communication of the project.
- Build and support proper foundation for short and long term documentation library and training programs.
- Set priorities for allocation of resources.
- Expedite decision-making.
- Make recommendations for policy decisions.
How the departmental Team is organized is listed within the PDD
Communication Plan
The implementation of a project will bring about significant business change within the implementing department and the success of the project will depend, in part, upon the effectiveness with which this change is managed. The following communication plan describes our strategy for keeping the project’s stakeholders sufficiently informed to avoid any disappointment regarding cost, schedule, or quality goals.
| Stakeholder | Information Needs | Frequency* | Medium |
| Steering Committee/ Sponsor | Changes to Timeline | As changes are requested | Memo from Project Mgr |
| Steering Committee/ Sponsor | Changes to scope | As changes are requested | Memo from Project Mgr |
| Steering Committee/ Sponsor | Changes to Cost | As changes are requested | Memo from Project Mgr |
| Steering Committee/ Sponsor | Status Updates | monthly | Web updates from Project Mgr |
| Implementation Team | Action Items | Daily | Excel |
*Daily, Weekly, Monthly
- Remember to identify
- Groups of end users needing targeted messages
- Messages for targeted groups
- Timing of messages and proper channels for targeted messages to reach end users
Change Management Plan
Once the PDD has been signed, any changes to Time, Scope, or Cost will need to go through a formal Change Request Process. The Change Request document will need to be submitted to the appropriate Vice President and the Steering Committee for approval before the change can be incorporated into the implementation plan.
Risk Management Plan
Throughout the project, the project staff will identify and respond to risks to the project with respect to the environment, user expectations, competing projects, project assumptions, resources, or any other relevant matter. Examples of risk include potential loss of a critical resource, technology changes, regulatory changes, dependence on a third party, scope changes, project sponsorship or management changes, and legal issues. Approaches to responding to risks include:
- Retention: The risk is acceptable; retain it and accept the consequences
- Deflection: Transfer the risk to another party.
- Preventive: Take action in advance of the risk event to reduce its likelihood or its impact.
- Contingent: Specify action that will be taken in response to a risk event, to mitigate its consequences.
- Avoidance: The risk is rejected; do nothing.
Risks identified at the beginning of the project are logged in the table below. A risk can be escalated to a Project Issue or Jeopardy after the project is initiated. One purpose of risk identification is to prevent a risk from escalating to an issue or jeopardy.
This table will be used to track risks identified during the project. If a risk becomes an issue or jeopardy, it must be designated as such below. In this table, Probability of Occurrence, Estimated Project Impact, and Weight are used to classify risks.
Risk Table
| 3 | Very Likely | 70-100% | 3 | Catastrophic |
| 2 | Probable | 40-70% | 2 | Critical |
| 1 | Unlikely | 0-40% | 1 | Marginal |
| Issue or Jeopardy Control No. | Risk (If…) |
Consequences |
P | I | W | Response |
| Unanticipated costs | Costs may be overlooked, leading to insufficient funds when project is already in progress | 1 | 2 | 2 |
Preventive/ Contingent. |
| Unanticipated issues with the Interface | Delayed implementation | 2 | 2 | 3 | Preventative. Understand the role each software will play early on. Ensure that testing is started early and monitor progress. |
| Delivered reports may not meet Residence Life Office’s needs. | Delayed implementation | 1 | 2 | 2 |
Preventive. Understand delivered reports, Ensure staff members have necessary training in use of query and reporting tools. |
| During implementation, decline in service level of the existing systems. | Unhappy customers. | 1 | 1 | 1 |
Preventive. |
|
Loss of staff critical to the project. |
System implementation delayed. | 1 | 2 | 2 |
Contingent. Critical positions will be filled as a priority. |
| Necessary resources are not committed to properly staff the project. | System implementation delayed. Quality of services will decrease | 1 | 3 | 3 | Preventive. Have backfills available. Develop training programs to rapidly educate replacement. |
| Assigned Project Members may not have time to perform project related activities, may not be directed to do so by their supervisors, or may not accept project as their job priority. | Project delayed | 2 | 2 | 3 |
Preventive. Monitor progress of all project team. Communicate with team members and their supervisors throughout the project concerning workload and ability to meet deadlines. |
| Short Implementation Schedule. Assigned Project Members may not have time to perform project related activities, may not be directed to do so by their supervisors, or may not accept project as their job priority. | Project delayed | 1 | 3 | 3 |
Preventive. Monitor progress of all project team. Communicate with team members and their supervisors throughout the project concerning workload and ability to meet deadlines. Allocate resources if necessary. |
| Hardware and/or software does not perform as expected | Delayed implementation | 1 | 3 | 3 |
Preventative. |
The Project Plan is considered complete once it has been signed off by the Project Team and the Project Sponsor.
Review Gate
Before the project can move into the Implementation phase of the Project Lifecycle, it must pass through the DIR Project Delivery Framework Planning Review Gate. The Review Gate is a series of questions that need to be addressed. Routing and signatures of the Review Gate Document may be required depending upon the Classification Level of the project (see below).
Level 1 Review Gate Document needs to be completed and submitted to the CIO of the implementing institution for approval
Level 2 Review Gate Document needs to be completed and submitted to the Project office of the implementing institution for approval
Level 3 Review Gate Document needs to be completed by the project PM and saved within the project file of the implementing institution.
The project is now ready to move into the Implementation Phase of the Project Lifecycle.
Level 1 Project
Level 2 Project
Level 3 Project
