The Project Schedule Part 4 – Resource Assignments And Estimates

Professor of Project Management Project Planning ,
Planning

Once you have defined your Work Breakdown Structure (WBS) the next step in creating a schedule is to assign resources and estimates to each task (the lowest level items in your WBS). A starting point in assigning resources is to consult the “Roles & Responsibilities” matrix you created as part of the Project Charter. You are looking for the stakeholders that are in the category of “helping you execute your project”.

You may find that some WBS tasks need resources that have not yet been specifically identified as assigned to the project. In this case you will meet with the managers of the areas that have the resource expertise and agree on the assignment. In other cases you may need to contract for professional services. This should have been included in your Project Budget and the Procurement Plan. If not, you will have to use the formal Project Change Management process to alter the budget to include these services.

Microsoft Project allows you to assign resources to a task. You can also assign the percentage of the resource’s time that will be dedicated to the task. In addition, you can assign more than one resource to a given task.

Once you have resources assigned to a task you can attach estimates. You can estimate using “Duration” (the length of time the task will take independent of the resources assigned) or “Effort” (the amount of hours or days a task will take given undivided attention of the resources). Which one you use will depend on the type of project, type of task and organization culture. As a general rule I like to use “Effort” and let MS Project calculate the duration given the resource percent allocation and other tasks assigned to that resource.

When defining estimates, take into account the expertise of the resource(s) assigned to that task. An expert resource may complete a task much faster than a novice. Sometimes estimates are placed on a task prior to the resource assignment to get an idea of how the schedule will look. If you do this, remember to re-estimate once the specific resource is assigned.

There are many techniques to creating estimates. I will not address them all here. The most common are:

  • We’ve done this task before so we know how long it takes
  • The assigned resource supplies the estimate. Be careful with this one. People tend to be overly optimistic on how much time a task will take.
  • A small group of people with expertise in that task are asked to independently estimate the task, then the group discusses the discrepancies and comes to a consensus
  • Management may dictate the duration of the task in which case the PM may have to assign resources with more expertise or add resources (if feasible) to meet the deadline.

You can also use a 3-point estimate (optimistic, pessimistic and most likely) and calculate your estimate using PERT (I recommend you Google this term for the details). For a more advanced scheduling technique, you can investigate “Critical Chain and Buffer Management”. This technique that will need organizational buy-in from the top down.

Note: Much more detail on creating a Project Schedule can be found in my Kindle book “Project Management For The Real World”, available at

https://www.amazon.com/author/lettera

#projectmanagement

Advertisement

The Project Schedule Part 3 – Work Breakdown Structure (WBS)

Professor of Project Management Project Planning ,
Planning

A Work Breakdown Structure (aka WBS) takes high level deliverables and breaks them down into lower-level activities suitable for assigning, managing and scheduling work. Creating a WBS is the first step in creating a schedule.

To build a project schedule, you must first define all of the activities that are part of the schedule. If you have created a Project Charter and a Project Plan, you have rich sources of information with which to define the deliverables and the activities needed to produce them.

The Project Charter contains the Project Objectives, which are products, services or results that the project will produce and will survive after the project is over. These are the ultimate deliverables of the project. The Business Objectives contain “Measures of Success” which may require the project to build measurement tools and processes. The Scope section contains high-level activities which can be broken down to smaller pieces for scheduling.

The Project Plan contains the “hows” of the project and most or all of the key project activities were defined there. As the Project Manager, you will need to decide at what level you will define the activities for scheduling purposes. As I mentioned in an earlier post, I am not a fan of Project Schedules that contain a large amount of activities as you will wind up putting more effort into schedule maintenance than the benefits you derive.

One common way to define the activities (create a WBS) is to start with the project deliverables and work backwards from there, asking the questions “What inputs are needed for this activity?” and “What activity creates each input?”. For example, for the Requirements Document deliverable, you need final approval. To get final approval, you need to conduct a review meeting. To conduct a review meeting, you need to schedule it. To schedule it, you need a draft document. To get a draft document, you need to write it. To write it, you need to schedule and conduct requirements gathering meetings. And so on until you reach the very first activity which either needs no inputs or the inputs have already been created.

If the deliverable is simple enough you can start from first activity and drill forward. Either method should work. For activities that are not yet well understood or defined, you can define high-level placeholders in the schedule and add the activities needed to obtain the required knowledge.

Once you have all of the activities, you will work on assigning the resources to the activities and defining the dependencies between activities. I will cover these topics in the upcoming posts.

Note: Much more detail on creating a Project Schedule can be found in my Kindle book “Project Management For The Real World”, available at

http://www.amazon.com/dp/b089krddvn

#projectmanagement

The Project Schedule Part 2 – Scheduling Tools

Professor of Project Management Project Planning
Planning

For anything but very small projects, you will need a tool to record and track your schedule. The most common tools used for this are Microsoft Project and Excel. They are not the only ones available but they are the ones I will discuss here.

Microsoft Project is a very robust scheduling tool with many features. You enter tasks and sub-tasks, assign resources (you can do this with varying percentages of availability), identify the effort needed for this task (in days or hours), and link the task to dependent tasks. The software automatically creates a schedule from this information.

Often on the first cut at creating a schedule, the project end date is beyond the desired target date. The sequence of tasks that directly connects to this end date is called the “Critical Path”. It is the longest path of dependent tasks in the project. This path of tasks are your top priority to monitor because slippage in any one of these tasks will increase the length of your project.

You must look for opportunities to bring the target date in line with expectations. You can do things like add more resources, bring in more skilled resources, look for opportunities to do tasks in parallel, and/or start some tasks earlier. Be mindful of budget, risk and quality implications when you use these techniques.

Excel can be used for small and some medium sized projects where you just need a list of key activities and the start and end dates. Unlike MS Project, Excel cannot create the schedule for you. It is used strictly for tracking and communication. It is much more convenient than Project when you don’t need all of the scheduling features.

I advise you not to create a schedule with so many tasks that it eats up your valuable project management time just maintaining the schedule. Create the schedule at a level sufficient enough to track the Critical Path and communicate status to key stakeholders. Keep in mind your Project Plan has all the activity details so there is no need to duplicate all of that information in the schedule.

Note: Much more detail on creating a Project Schedule can be found in my Kindle book “Project Management For The Real World”, available at

http://www.amazon.com/dp/b089krddvn

#projectmanagement

The Project Schedule Part 1 – Overview

Professor of Project Management Project Planning
Planning

Now that you have a Project Charter, a Project Management Plan and a Project Plan, you can construct a detailed schedule. As mentioned in an earlier post, many refer to the Project Schedule as “The Project Plan”. Since the schedule does not detail how and where tasks are going to be accomplished, it is not “the plan” but is a component of the complete plan. That is why we have a separate document for the Project Plan.

In the upcoming posts I will present the following topics related to constructing a Project Schedule:

  • Part 2: Schedule Tools
  • Part 3: Work Breakdown Structure
  • Part 4: Resource Assignments and Estimates
  • Part 5: Dependencies
  • Part 6: The Critical Path
  • Part 7: Schedule Adjustments (Crashing and Fast-Tracking)

My book, “Project Management For The Real World”, is available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

#projectmanagement

The Project Plan Part 9 – The In-Project Support Plan

Professor of Project Management Project Planning ,
Planning

The In-project Support Plan is needed if all or part of the solution is to be supported by a vendor or 3rd party. It addresses support needed during the project which includes the post-implementation stabilization period.

Here is a list of some things to consider (this is not necessarily the complete list of considerations; your project may have more):

  • Scope – describe the conditions in which this support is triggered.
  • Contact information – phone #’s, email, website, customer access id
  • Service Level Agreements (listed in order of severity, commits to how fast you can expect a response to a reported issue)
  • Problem and Status Reporting – what tools will be used, roles, responsibilities
  • Escalation Procedure if issues are not addressed in a timely or effective manner
  • Change Requests – for changes that are not bugs, define the request procedure & labor rate

This topic concludes the series on “The Project Plan”. In the next series of blog posts, I will address development of the Project Schedule.

My book, “Project Management For The Real World”, is available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

#projectmanagement

The Project Plan Part 8 – The Post-Live Support Plan

Professor of Project Management Project Planning ,
Planning

The Support Plan describes how the solution will be supported once operational. This includes a description of the support personnel and their roles as well as the processes to resolve problems arising within the solution boundaries.

Implementing a Support Plan is an important piece of Project close-out. The operational Stakeholders must be self-sufficient once the solution is live and no longer dependent on the Project Manager. Lack of a Support Plan is the primary cause of Project Managers being attached to projects for a long period of time after go-live.

Here is a list of some things to consider when building your Support Plan (this is not necessarily the complete list of considerations; your project may have more):

  • Support Resources, Roles, Responsibilities
  • Support model – define who will function as level 1, 2 & 3 support, how they will be contacted, and their staffing needs
  • Service Level Agreements (e.g. system availability, up-time, response time, etc)
  • Help Desk support
  • Vendor Support (support that will be purchased from the vendor) including naming the Stakeholders that will be the vendor support point of contact
  • Specialists (describe circumstances in which in-depth knowledge of the solution requires engaging specialists)
  • Product Updates – Who is responsible? Software vendors typically release updates multiple times a year. How often do we plan to apply them? How will it be tested? What is the roll-back plan? Who will monitor changes in platform support?
  • Include both one-time and ongoing costs for the items listed above

My book, “Project Management For The Real World”, is available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

#projectmanagement

The Project Plan Part 7 – The Deployment Plan

Professor of Project Management Project Planning ,
Planning

The Deployment Plan describes the factors necessary for a smooth deployment and transition to ongoing operations. It encompasses the processes of preparing, installing, training, stabilizing, and transferring the solution to operations. For some projects, deployment can be very complex. For these types of projects it pays to start deployment planning as early as possible to manage the risk of delays due to deployment difficulties.

Here is a list of some things to consider for your deployment plan (this is not necessarily the complete list of considerations; your project may have more):

  • Scope
    • Stakeholders (those affected by the solution)
    • New and changed Business Processes
    • Licensing considerations
    • Approx. # components per platform
  • Deployment strategy & schedule (e.g. phased, site-by-site, push vs. pull, dept. by dept, etc)
  • Organizational Change Management
  • Implications of new and old system and processes in production at the same time
  • Deployment Resources
  • Help Desk Preparation
  • Desktops/Servers Affected
  • End User Training (High level business process and detail usage)
  • Installation Process
  • Installation Validation
  • Support during Stabilization
  • Hand-off to Support and Operations
  • Activation of Monitoring (for computer systems and business processes)

My book, “Project Management For The Real World”, is available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

#projectmanagement

The Project Plan Part 6 – The Pilot Plan

Professor of Project Management Project Planning ,
Planning

Some organizations define a solution “pilot” as a “limited deployment” for the purpose of managing risk. That can be covered in a Risk Management Plan in lieu of a Pilot Plan. The definition we will use in this post is to use a Pilot to gather information about the solution that can only be discovered by “going live”. The intent of the Pilot is to obtain the information and then pull the solution out of the live environment for additional work.

The Pilot Plan describes what aspect of the solution will be delivered as a pilot and provides the details necessary to conduct the pilot successfully. This includes details on how to evaluate the pilot, the results of which will facilitate a decision whether or not to move the solution to production. Projects often create one or more “pilot” solutions for the purpose of proving the feasibility of solution approaches, experimenting with different solutions, and obtaining user feedback and acceptance on proposed solutions. Pilot solutions usually implement only those subsets or segments of requirements or functional specifications necessary to validate a solution.

The Pilot Plan provides the means to validate business requirements and technical specifications prior to deploying the solution into production. Planning the details of the pilot ensures that the participating project teams identify their roles and responsibilities and resource requirements specific to pilot development, testing, and deployment activities.

A pilot can provide key information on development processes, end-user validation, and production environment usage. It also provides feedback to stakeholders regarding the success of the solution once it is formally released.

Note that Pilot Plans are not just for IT projects. For example, fast food chains will often test new menu items for a limited time in a small number of locations to gauge consumer interest and test the store’s ability to deliver the product successfully.

Here is a list of some things to consider documenting as part of the Pilot Plan (this is not necessarily the complete list of considerations; your project may have more):

  • Overview – Scope (what part of the solution will be demonstrated as part of the pilot, and the target user profile used to select which users will participate)
  • Success Criteria and Metrics – The success criteria may fall into the following categories:
    • System performance
    • Operations cost
    • Stability –down time
    • User performance
    • User satisfaction
    • Business goals
  • User Preparation and training
  • Marketing Plan – how users will become aware of the pilot and the value to them
  • Conditions for adding additional users
  • Rollback – conditions for rolling back the pilot to pre-deployment state
  • Pilot Evaluation – describes how the pilot results will be evaluated

My book, “Project Management For The Real World”, is available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

#projectmanagement

The Project Plan Part 5 – The Migration Plan

Professor of Project Management Project Planning ,
Planning

The Migration Plan describes the migration from existing systems or applications to the new solution. This plan is needed whenever you have to salvage anything (data, artifacts, physical objects, etc) from the old environment to the new one. In some projects this can be very challenging and the source of a lot of effort so plan early and carefully.

It is important to have an understanding from your sponsor of the Business Objectives driving the migration. Keep in mind each objective will have associated costs and risks. Examples of these are:

  • Minimize Business Disruption
  • Stay in full compliance with laws and regulations
  • Keep migration costs as low as possible
  • Choose acceptable alternatives that avoid risk to the target implementation date

Here is a list of some things to consider (this is not necessarily the complete list of considerations; your project may have more):

  • Migration Strategies (alternatives, including tools and implications for each)
  • Migration process (how, when and by whom the migration will be performed)
  • Test Environment (Setup, timing, hardware, people)
  • Preparation (Everything needed to be ready to execute the Migration Plan)
  • Decommissioning of replaced resources (timing, disposal)
  • Back-out plan (what to do if something goes wrong with the migration)

My book, “Project Management For The Real World”, is available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

The Project Plan Part 4 – The Test Plan

Professor of Project Management Project Planning ,
Planning

The Test Plan applies primarily to projects that include new and changed software and/or business processes. Doing this planning in advance is key to meeting the target schedule as testing is typically the most time consuming portion of a project. Unfortunately, when many projects are in schedule trouble, testing is usually the first target for cutting the planned effort. Having a solid Test Plan will help mitigate that risk.

There are multiple aspects to the test plan:

Determine the Test Plan Objectives by Identifying…

  • …the activities required to prepare for and conduct testing
  • …the test scope, strategy and methodology to be used for the test
  • …the financial control tests (if applicable)
  • … the configuration controls and metrics
  • … the metrics and status reporting
  • … responsibilities for the tasks included in the plan
  • … test tools and the environment needed to conduct the test
  • … test interactions with other organizations
  • … test customers and deliverables
  • … the major testing milestones
  • … the sources of information used to prepare the plan

Define the Test Approach:

Give a high-level description of the approach and activities to be followed in testing the solution. If you are using Agile methods, this is where you will plan the release/test cycles.

Identify the Major Test Responsibilities:

Identify teams and individuals who will be managing and executing the tests. It should also specify their responsibilities.

The Features and Functionality to Test:

This is a high-level description (not the detailed test cases). You should consider the following:

  • Specific features to be tested
  • The types of error testing to be performed
  • The types of stress/load testing to be performed
  • The type of usability testing to be performed
  • The type of reliability testing to be performed
  • The type of recovery testing to be performed
  • The type of compatibility/migration testing to be performed
  • The type of security testing to be performed
  • The types of software and hardware to be employed if testing is to be performed over multiple software and hardware configurations (configuration testing)

Document your thoughts on the test process:

You should consider the following:

  • How you will define the acceptance criteria
  • Deliverables – materials that must be made available or created in order to conduct the tests and that will be developed from the tests to describe the test results.
  • Test Documentation – itemize the documentation you will require in regards to recording the test procedures and results.
  • Test Data – Where will it come from? How will it be created? Are regular refreshes needed?
  • Support Organizations – identify all interfacing organizations (Technology Services, Vendors, etc) that are needed to support the testing. Describe what will be needed.
  • Test Setup, Procedures and Walk-thru – general description of the steps the test will go thru to ensure quality tests.
  • Tracking and Reporting Status – Define the information test team members will communicate during the testing process. This should include the bug reporting tools and methods as well as a bug classification strategy

My book, “Project Management For The Real World”, is available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn