University of New England
Project Process Narrative
TABLE OF CONTENTS
1 STARTING A PROJECT...3
1.1 IS IT A PROJECT?...3
1.2 WHAT DO I DO IF IT IS A PROJECT (INITIATION PHASE)?...4
1.3 WHAT IF THE PROJECT IS RECOMMENDED TO GO FORWARD?...4
2 EXECUTING A PROJECT...4
2.1 FIRST STEPS (THE PROJECT CHARTER)...4
2.1.1 Project Purpose and Justification...5
2.1.2 Project Scope and Deliverables...5
2.1.3 Project Resources...5
2.1.4 Project Critical Success Factors/Business Objectives...5
2.1.5 Project Acceptance Criteria...6
2.1.6 Project High Level Assumptions...6
2.1.7 Project High Level Risks and Mitigation...6
2.1.8 Project Roles and Responsibilities...6
2.1.9 Project Phases and Key Milestones...6
2.1.10 Implementation Plan...7
2.1.11 Estimated Project Budget...7
2.1.12 Document History...7
2.1.13 Attachments...7
2.2 NEXT STEP (PLANNING PHASE & THE PROJECT WORKBOOK)...7
2.2.1 Instructions...8
2.2.2 Contact List...8
2.2.3 Communication Plan...8
2.2.4 Requirements...8
2.2.5 Risks...10
2.2.6 Issues...11
2.2.7 Schedule...11
2.2.8 Change Requests...11
2.3 EXECUTING THE PROJECT (EXECUTION PHASE AND SUPPORT TEMPLATES). .12 2.3.1 Consolidated Project List...12
2.3.2 Project Risk Evaluation...13
2.3.3 Project Roles and Responsibilities...13
2.3.4 Monthly Status Update...13
2.3.5 Project Weekly Status Report...13
2.3.6 Project Status Meeting Minutes...13
2.3.7 Project Action Item Log...13
2.3.8 Project Test Cases...13
3 ENDING A PROJECT...14
3.1 IMPLEMENTING THE PROJECT (IMPLEMENTATION PHASE)...14
1 Starting a Project
1.1 Is it a project?
One of the 1st things to do when starting an activity at UNE is to decide of this activity should be a project or not. Generally routine activities or tasks that can be completed in a few weeks do not require a project structure. For our purposes, a project is a temporary activity with a starting date, specific goals and conditions, defined responsibilities, a budget, planning, an end date and multiple involved parties.
Small projects may not require a formal structure but might pick and choose some of the project templates that are available in the UNE project management
process. Many projects that are completed inside a single department might fall into this category.
Larger projects that expend a significant amount of resource time, involve multiple departments or expend UNE budget dollars require a formal project organization.
1.2 What do I do if it is a project (Initiation Phase)?
Is it a Project?Routine activity or task?
Not a Project
Small Project?
Pick useful templates and proceed
Refer to Project Management Process Flow
$0 External Budget? Single Department?
Limited Risk? Short Duration?
Yes
Yes
This is a Formal Project
No
If you have formal projects then refer to the Project Management Process flow diagram. This first thing to do is to make a copy of the Project Charter template and complete the first two sections. These two sections include a description of what problem the project is to resolve or opportunity that the project will exploit. This should include a justification (or ‘selling points’) of why this project should be approved. There is also a section to describe the overall scope of the project and any specific deliverables that the project should produce.
The next step is to take the project to the appropriate Senior Administrator. This is likely the Senior Administrator in your area. The Senior Administrator will review the project Purpose and Justification and Scope. They may then require changes to the document, approve the document to go forward with their recommendation or decline to proceed with the proposed project.
Assuming that the Senior Administrator has recommended the project to go forward, the next step is to take the Project Charter to the appropriate review committee for discussion and approval. Examples of review committees would be the Academic Technology Council or the Administrative Technology Council. If there is no relevant review committee then the Charter can be taken directly to the IT Council.
The review committee would discuss the proposed project and may make
recommendations to revise the proposal, decide not to proceed with the project or make a recommendation to the IT Council to proceed forward with the project. A decision not to proceed may be due to a number of factors – the review committee may not be convinced of the need for the project, the necessary budget may not be available, or the timing may not be right to start the project. If a recommendation is made to go forward with the project then the process proceeds to the next step. If a Business Owner and Project Coordinator have not been selected, the review committee may make that selection.
1.3
What if the project is recommended to go forward?
If you’ve successfully made your case for the project and the review committee and the Senior Administrator recommends that the project go forward then it gets presented to the IT Council for approval. The IT Council will also review the project and justification and consider it in connection with other potential projects, resource commitments, budget availability and other factors. If the IT Council approves the project to start then the review committee will be informed and the project can proceed forward.
2.1 First steps (The Project Charter)
Once you have approval to proceed with your project then you’ll need to fill out the rest of the Project Charter. Recall that only the first two sections were required to get approval. The rest of the sections will further flesh out the project. Once you complete the entire Project Charter, including the estimated budget and timeline then it goes back to the IT Council for final approval. Here’s a rundown of the Project Charter –
2.1.1 Project Purpose and Justification
This section should have been completed by now. This should clearly describe the issue that the problem will address – what problem are you trying to solve; what regulatory requirement will you be implementing; what new idea or opportunity will you be taking advantage of; what business process, construction project, business improvement will you be completing? This also describes the benefits of completing this project – cost savings, efficiency improvements, new functionality, etc? In other words – why should UNE expend time and money on this project?
2.1.2 Project Scope and Deliverables
This section should also have been completed during the Initiation Phase. In this section you’ll detail out the scope of the project. The scope defines the project boundaries. It should describe the goals that the project should accomplish. Note the option for listing Out of Scope items. This can be used if there are objectives that may have been discussed but have been specifically determined to be outside the boundaries of this project. Listing these items here can prevent confusion later in the project when the discussions may not be remembered clearly and people may make assumptions about what may still be in scope or late in the project the same items come up as requests to be added to the scope.
Specific required deliverables should also be listed here. User manuals, business documentation, software installations, or specific reports are examples of
deliverables.
2.1.3 Project Resources
Project Team members are listed here. Be sure to include the Business and Technical Subject Matter Experts (SMEs) there are on the project team. Also include any 3rd party vendors that may be involved. The project resources may
come from multiple departments. You may also list various project stakeholders who may not be part of the project team but have in interest in the project progress or outcome. Detailed contact information can be added to the Contact List in the Project Workbook if desired.
2.1.4 Project Critical Success Factors/Business Objectives
have been achieved. Some factors may be achieved and this may lead to future project endeavors.
2.1.5 Project Acceptance Criteria
Acceptance Criteria may be related to Success Factors but can be a more detailed list of specific acceptance criteria. This criterion will be used to determine if the results or deliverables of the project are accepted by the Sponsor/Business Owner and the project can be successfully completed and closed. The General Acceptance Criteria is a list of overall Criteria such as noting that all project deficiencies/issues have either been resolved – either by fixing the issue, recognizing and accepting the issue as is, or by developing a resolution plan to address the issue after the project is closed. The Project Specific Acceptance Criteria is based on the specific project and might list specific deliverable items such as software xxx has been successfully installed; a training guide has be produced and approved by the department; a training class has been held, etc.
2.1.6 Project High Level Assumptions
Some assumptions may be important enough to list in the Charter. These are various conditions that are ‘assumed’ to exist as a baseline for the project to be successful. Valid, and important, assumptions might be that a key project team member is available throughout the project; or a certain software product currently being implemented in a different project will be available for use by this project. Projects dealing with new technology may make an assumption that the new technology will work as necessary in the technical environment or that a vendor can be found to supply the technology at a price within the allowable budget.
2.1.7 Project High Level Risks and Mitigation
Somewhat related to Assumptions are project risks. An assumption might be that a key team member is available for the project. A risk may be that they are not. If this person is truly a key member then it may be necessary to develop a risk mitigation strategy around not having this person available for the project. Other risks may relate to having a short timeline or a fixed regulatory deadline. List the high level risks here as well as what the project will do if a risk materializes – this is the mitigation strategy. You can capture this information here in the Charter at a high level. The project workbook contains a Risk tab where you would record more detailed risk information.
2.1.8 Project Roles and Responsibilities
A listing of the project roles can be added here for reference. If you use this section be sure to include information on what each project role will be responsible for. This can help define what each project role is responsible for in the context of this project. The project template documents folder contains a Roles and
Responsibilities document that has defined some of the major project roles and what they would perform.
2.1.9 Project Phases and Key Milestones
things such as an RFP release date; RFP response date; key decision dates; go-live dates, etc.
2.1.10 Implementation Plan
This is the project schedule and should include all significant project tasks and milestones. The key milestones from the prior section should also be included here. Recall that a milestone is a distinct act such as a decision made; an
implementation completed, etc. so that a milestone will always have the same start and end date.
This implementation plan format should work for many projects, particularly small ones or uncomplicated ones. If you would prefer to use the schedule tab in the Project Workbook, a separate Excel spreadsheet, or Microsoft Project for creating and maintaining the project schedule then this entire section can be deleted from the project charter.
2.1.11 Estimated Project Size/Complexity
It is important to determine the estimated size/complexity for all projects. Project size and complexity is determined by a combination of the effort involved, the number of people needed to be involved, the number of different departments involved, whether or not outside parties (vendors, outside partners, etc.) are needed, etc. This is just an estimate that is used during project approval and during the planning phase to help determine reasonable timelines, resource commitments, risks, etc.
2.1.12 Document History
This section is used to record the change history of the Project charter document. Not every change needs to be noted here but when major additions or modifications are made they should be recorded here. This is particularly true if material modifications are made after the charter is reviewed by the Senior Administrator or the IT Council.
2.1.13 Attachments
Include either by reference or by embedding documents into the Charter document. Attachments may include items such as MS Project Plans, vendor quotes, detailed designs, charts, etc.
2.2 Next step (Planning Phase & the Project Workbook)
Once the IT Council has approved your project and you’ve completed the Project Charter you’re ready to proceed to the Planning Phase. It is critical to project success that this phase be done right. Oversights or incomplete planning can result in some very expense and time-consuming rework during the later phases of a project – it’s best to know all the requirements for a piece of new software before you buy it!
participate, that they have sufficient time available to do so and 3) you’ll want to review everything in the Project Charter so that the team understands the scope and purpose of the effort. You’ll also want to determine how often the team will meet; weekly status meetings are good, bi-weekly may work out if the team members are normally in contact with one another. It is important to schedule regular meetings to mark progress and keep everyone one track. Meetings also serve to bring potential issues to light or answer questions and provide
clarifications before things can go far off on the wrong track.
The Project Workbook will be your primary project document at this point. Here’s what you can find in it:
2.2.1 Instructions
This is an overview of each of the other tabs in the workbook and how they would be used. If you decide to add additional tabs to your project
workbook then be sure to add descriptions of them here.
2.2.2 Contact List
This tab should include all project team members and their contact information (email; phone). If 3rd party vendors are involved in the project then their contact information should be listed here also. This provides all project team members with a central listing of contact points.
2.2.3 Communication Plan
This tab already includes some standard meetings and update
communications. If there is something listed in the Template column then there is template available for this meeting/communication. This chart shows the purpose of each communication, who is primarily responsible for organizing/leading the meeting, who should be invited to the meeting, how often the meeting should be held and any templates that can be used to facilitate the meeting. All of these communications can be updated to reflect the specific project. Other communications can be added to this list – examples might be roll-out announcements, training sessions, vendor conference calls, etc.
2.2.4 Requirements
This tab will contain some of the most important pieces of information about the project. This should contain all of the detailed requirements of a
project. Requirements are all of the things that a project must accomplish. This are line item descriptions of what the project must do. For software projects, these are the technical and functionality requirements (i.e. must run on a Windows Server 2008 platform; must us an Oracle or SQL Server DB; must require a userid and password; password must require change at least every 90 days; screen background must be blue; must be available via the college website; must have capability to send reminder emails, etc.).
Other projects can have other requirements (Orientation tables must be set up and staffed by 9:00am; Wireless connections must be available for each department staffing a table; Tables must be staffed from 9:0am until 3:00pm; Student orientation groups must no larger than 20; Student
Requirements must be written to meet the following standards:
Correct - They must be accurate. Accuracy should be verified by having
the person/people most familiar with the requirement to review and approve it.
Non-contradictory – requirements cannot contradict each other or be
mutually exclusive.
Complete – The requirements as a whole must completely describe the
new system, process or desired result.
Feasible – They must be doable within the scope, timeline and budget of
the project as well as technically feasible.
Necessary – They must be necessary to the purpose of the project. If the
project can be accomplished without a requirement, then it is not Necessary. Such a requirement may still be listed, but it should be marked as Important or Desired but not Critical or Required.
Unambiguous – the requirement must be clearly written so that there are
not multiple interpretations of its meaning.
Verifiable – The Acceptance Criteria must be clearly articulated so that it is
clear when a requirement is met.
The requirements worksheet has some additional information beyond the requirement description.
Category can be used to separate requirements into functional and
technical categories. For instance – Functional: System must automatically
send an email to Students one day prior to the 1st class day if they have not
fully paid tuition. Technical: System must integrate with Microsoft
Exchange 2008 for email sending capabilities
Priority is used to define requirements as Critical – this requirement must be met for the project to succeed. Required – this project is required for project success, but if there is no way to implement it, the project may still be considered at least partly successful. Important – this is an important requirement but there may be a workaround if this requirement cannot be met (i.e. an important piece of business functionality that none of the software under consideration will do). Desired – this is a ‘nice-to-have’ bit of functionality that, if possible, can be implemented.
Status is used to set the state of a requirement. A requirement is either New – it’s just been added to the list; Approved – the Budget Owner and project team has reviewed the requirement and has agreed that it should be part of the list and is prioritized correctly; Cancelled – a previously approved requirement has been removed from scope (due to factors such as design or scope changes, timeline constraints, budget constraints, etc.).
2.2.5 Risks
Project risks are important to document and track early in a project and also as additional information is learned as the project proceeds. Risk
management is an important aspect of project management. A risk discussion should occur early in the project where potential risks are identified and documented. Project risks may be internal, such as key project team members not being available for critical parts of a project, or external, such as a vendor not delivering on a product or service at an agreed upon time. Think of risks to meeting the scope or requirements of a project, the timeline for delivery, or the project budget when doing a risk analysis. Write a good description of the risk and assign a Risk Owner to monitor the risk and take action if necessary.
Initially a risk will have a Status of Open. If a risk has a limited range then it may change to Expired. An expired risk is no longer a threat to a project. For instance, the risk that an RFP will not be send out by a certain date expires once the RFP is send out on or before that date. A risk that has actually materialized and impacted the project is changed to Realized. After defining the risk, make a judgment of both the probability of the risk actually materializing and the overall impact to the project if it did. This will generate a risk score. The risk score works as shown below.
Impact
Probability Low Medium High
High 3 6 9
Medium 2 4 6
Low 1 2 3
A risk score that is Yellow or Red should have a Risk Response plan defined.
The Risk Handling approach has the options of Accept – choosing this option means that you have decided to accept the risk and not set up a risk mitigation plan. This might be a viable option of the impact is low and having the risk materialize will not jeopardize the success of the project. Transfer – this option means that you’ve arranged to transfer the risk to someone else. Hiring a 3rd party to do some work may effectively transfer the risk to them if you have sufficient safeguards in the contract such as penalty fees or cancellation options for non-performance. Mitigate – this means that you have a defined risk response plan ready to implement if this risk materializes. Mitigation plans may be having a backup vendor
available; reducing project scope; using budget contingency, etc.
2.2.6 Issues
Every project has issues that arise during the course of the project. Issues are circumstances that arise during the project that, if left unresolved, can cause a risk to the project’s success. It is important to document issues so that they can be discussed, escalated if necessary, and resolved before they have a chance to impact the project.
Issues have a description of what the problem or potential problem is. This could be something like ‘vendor has not provided an installation schedule; a schedule is needed in order to develop the rollout communication
brochure.’ The severity of the issue is determined by the potential impact to the project. A Critical severity might be an issue that, if unresolved, could result in the cancellation of the project. Record the date the issue was recorded and the date at which it is expected to be resolved (or is required to be resolved before impacting the project). Each issue must have an owner (assigned to) who is responsible for resolution. The owner does not have to be the one actually resolving the issue, but will be taking the actions necessary to ensure that it does get resolved. Any issue can be Open (i.e. identified), In Progress (resolution is progress) or Closed (i.e. resolved or no longer applicable).
Note that project issues might be resolved within the project or may require escalation to the Senior Administrator or the IT Council. Be sure to
escalate issues in a timely manner to minimize impact to the project.
2.2.7 Schedule
This tab is to used to set up and track the project schedule. Enter a project start date in the first date field (Week), subsequent dates will auto-populate. Making the start date a Monday will simplify the date scheme.
Set up a project schedule for all projects. If you don’t yet know many of the dates or durations make an estimate (guess!) and document it. Don’t be afraid to change it later when you have more information.
This schedule tab should work for many projects. If a separate schedule is desired, using MS Excel or other tools such as MS Project, then this tab is not necessary. Some type of schedule is needed however to track project actual progress against plan.
Set up the schedule by filling out the significant tasks for each phase. Include the milestones from the chart below the timeline. Just shade the cells covering the estimated duration of each task. Modify the Milestone Chart to fit your project. The default ones are some generic milestones to get you started.
2.2.8 Change Requests
set and, when necessary, reset expectations for a project in the minds of the stakeholders. After the Planning phase of a project any requests that result in increases or decreases to the project scope should be recorded here as well as anticipated impacts to the project. For instance, a request to shorten the timeline for an earlier delivery may result in reduced scope upon delivery. On the other hand, adding new functionality may result in increased cost or a later delivery. All of these things are okay in a project as long as they are recorded, evaluated, and approved with recognition of the impact on the project.
Change requests must be reviewed and approved by the Senior
Administrator before being incorporated into the project. Change requests that are made but not approved should also be documented so that they aren’t discussed multiple times and to prevent post-project confusion (i.e. Q: “Why doesn’t this do ‘XYZ’? We clearly discussed this during the project.” A: “Yes, we did discuss it, and that change was not approved by the Sponsor – see Change Request #14”)
2.3 Executing the Project (Execution Phase and support templates)
At the end of the Planning phase you should have all of the project requirements documented and agreed to, the major project risks identified, documented and have risk mitigation plans defined. You should also have the major project milestones identified and an estimated timeline worked out. At this point you’ll be ready to give an update to the IT Council and your Senior Administrator and, assuming that things still look good, proceed on the Project Execution. The Execution Phase is where the bulk of the project work occurs. If your
requirements lead to an RFP then the RFP will be written, issued and awarded during project execution; if software modifications are required, then this is where they will be done and tested; if a new ball field is to be constructed, then this is where it will happen.
Throughout the execution phase you should be reviewing the requirements to ensure that they are still relevant and complete. If requirements are found to be not relevant or incomplete, then change requests should be created and
approved to modify the requirements. Also, the project risks will need to be monitored to see if any might be realized. The mitigation plans will need to be activated if a risk does materialize. New risks might be identified and will need to be documented. Issues will need to be documented, escalated if necessary, and resolved. Your project schedule will have to be monitored and adjusted if
necessary with the appropriate communications going out to the project stakeholders, including the IT Council if the schedule needed to be changed.
There are a few additional project templates that can be used to assist in all of this project activity. Here’s a brief description of them:
2.3.1 Consolidated Project List
Owner and/or Project Coordinator (possibly using the Monthly Status Update) when preparing this list for the IT Council.
2.3.2 Project Risk Evaluation
This is just a general aid to assist in identifying project risks. This can be used, particularly on large projects, to do an initial risk evaluation when first filling out the Project Risk tab in the Project Workbook.
2.3.3 Project Roles and Responsibilities
This is an aid in defining the general project roles and the responsibilities for each role. A copy of this can be made and the roles and responsibilities
modified to fit a particular project or this can be referenced in the Project Charter as appropriate.
2.3.4 Monthly Status Update
This is standard template that should be used to give regular updates on project progress to the Senior Administrator and the IT Council. The CIO may request this updates when updating the Consolidated Project List for presentation to IT Council.
2.3.5 Project Weekly Status Report
This should be used to give regular updates on project progress to the Business Owner and to the project team members. It can be used during the project status meetings to discuss and plan upcoming activities and project issues/risks.
2.3.6 Project Status Meeting Minutes
This should be used to record the discussions during the project status
meetings. Also, any action items that are assigned during that meeting can be recorded for distribution to the project team. These action items should be added to the Action Item Log.
2.3.7 Project Action Item Log
This is a project aid that can be used to track individual tasks or action items that need to be accomplished during the course of a project. These action items are typically assigned to a project team member. Listing action items assures that project tasks get are all assigned owners and due dates so that they can be tracked to completion. This are not project issues, but just ‘things that need to be done’. Assigning due dates and team members helps organize the tasks and keep the project on schedule.
2.3.8 Project Test Cases
This template is used to document the project testing. Test Cases are not restricted to software testing only. Test cases may be used for software customizations, third party software implementations, hardware
Additional project documents may be required during the course of any project. This is not meant to be an exclusive list of all project documents. If other documents are found to be useful for many projects then create a template that will work, add it to the list of Project Management templates, incorporate it into your process and start using it.
3 Ending a Project
3.1 Implementing the Project (Implementation Phase)
Once your project is ready for Primetime – it’s been built, tested, approved – ready for real life use, then it time to begin the Implementation Phase. For things like software or hardware then Implementation means that you’ll be moving the functionality into the production environment and start using it ‘for real’. Implementation for a new business process might mean that you’ll stop using your old process/workflow and start using your new one in ‘production’ and monitor it to be sure that everything works as planned. Implementation for an event means that the event flyers will go out and the event will be held (i.e. annual student orientation). Implementation for a facilities project might mean that the new building/room/parking lot/ball field is ready for public use.
This phase is where all the planning and execution come together to produce your project deliverables, whatever they may be. In any case, you’ll be monitoring the implementation progress and evaluating any implementation risks that you have documented in case you have to activate any of the mitigation plans (revert back to old software if the new doesn’t work as expected; delay opening the parking lot if the striping isn’t complete; bring the orientation events indoors if it’s raining, etc.).
Once you have fully implemented your project – check your Project Charter for the Deliverables and Success Criteria that you defined at the beginning – you’ll be ready to review it with your Senior Administrator and obtain approval to close the project.
3.2 Ending the Project (Closeout Phase)
Project Closeout is just tying up the loose ends. Closeout might consist of checking the project documentation to make sure that all risks are closed, issues are resolved and deliverables are complete.
Any turnover of documents or activities to be transferred to others at the conclusion of the project (i.e. training materials for ongoing training; support activities; post-project issue management, etc.) has been completed. Lessons Learned are communicated so that they don’t become Lessons Repeated.
