Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Why are we putting so much focus on standardizing the project management process across the entire department?

Standardizing the project management process allows us to deliver outcomes in a repeatable and deliberate way, measure and track efforts consistently, and use data to anticipate problems early and course-correct. Ultimately, it leads to improved customer service and proven track record.

Building a project plan is not much more than:

  • Identifying patterns across a body of work
  • Breaking down and simplifying each pattern into further details
  • Estimating details independently and in an unbiased way
  • Repeating until not much more needs to be known

This process of simplifying the problem allows us to reduce the project unknowns.

There are many ways to achieve this goal. ITS has adopted a simple methodology based on breaking down a project into “what is being delivered” and “how it will be delivered”, dubbed the ITS PRO Ontology.

These are the must-have components of a good project plan:

  1. CHARTER: States the objectives of the project and key stakeholders.
  2. OBJECTS: The tangible and concrete deliverables needed to complete the project. They are described using a noun, are clear and understandable by the clients, and are a commonly repeatable item. They are things like a requirements document, one function of a software product, a reusable API, or a single server instance.
  3. PHASE: A way of grouping activities to show the state of the work, think of them as "tags" on the individual tasks. This is an additional layer of information that can be used to glean information about our project management process. Examples of phases include things like Initiation, Definition, Design, Development, Test, Deploy, Control, Closeout.
  4. MILESTONES: The key points in time that sponsors care about, the highest-level accomplishments towards the end goal. Example: Project Requirements Complete and Delivered, Online Reports Tested, Product Deployed and Operational.
  5. TASKS: The action required to produce the deliverable. Tasks are described using a verb and include specific details like who is responsible for the work, how long it will take, and when it will be done. Examples of specific tasks: Modify firewall on vlan 121 to allow ssh traffic, Send scope document draft to project team for review and feedback.

Here’s an example of what an Object and its associated tasks could look like:

ObjectTask
Scope Document for Data Center Migration projectDocument all systems and services that need to be migrated by asking the subject matter expert (SME)
 

Create initial scope document draft

 

Send scope document draft to project team for review and feedback

 

Review and integrate feedback

 

Send scope document to Sr. Leadership team to review and sign-off

 

Publish final version of scope document

To get a better understanding of the ITS Project Ontology, watch this short introduction video, courtesy of Kal: 8-minute Project Ontology video

Recommended Approach for the Project Plan

When either entering or evaluating projects and their ontology, this is the recommend order of thought:

  1. Project charter: Obtain and understand the purpose and value of the project
  2. Object list: Define all deliverables in easy-to-undertand terms
  3. Phase list: Think about the phases that project will go through
  4. Staff list: Identify project team members, their roles in the project
  5. Milestone list: Identify the key points in the project that are important to stakeholder/clients.
  6. Task list: Determine specifically what needs to be done to deliver the objects, meet the project goals.

When preparing a project plan, first ensure the charter is assembled and then enumerate an object list for the project without any regard for tasks, etc. It should be a simple list of just objects, clearly worded, and their assigned /wiki/spaces/ITSPRO/pages/67403853, nothing else.

The next step is to determines what phases will be needed for the project in a simple and separate list.

Then the project team list should be determined, along with their roles. They represent who will enter time on the project and what roles each person will take.

Finally, the task list is assembled, combining (and assigning each to a task):

  • The staff list
  • The milestone list
  • The object list
  • The phases

The idea behind this recommended, step-by-step approach is to illustrate that breaking down the project into clear parts is the essence of good project management.

Resources:

  File Modified
No files shared here yet.

 

 

  • No labels