More schedule tasks to do before you baseline
Categories:
checklist,
stakeholders,
Schedule Management,
Cost Management,
Stakeholder Management,
Scheduling
Categories: checklist, stakeholders, Schedule Management, Cost Management, Stakeholder Management, Scheduling
| Last month, I wrote about 3 things to include in your schedule creation activity before you could say your schedule is ready for use, after you’ve created the work breakdown structure and added in dates, dependencies and task owners. Here are another 3 things you can build into your project planning tasks to polish your schedule. 1. Add in the costs One thing we’re doing at work more and more is cost loading schedules. You don’t have to do this in your project scheduling software unless it makes sense to do it there. You could also create a phased version of your budget that shows when costs are going to hit. Adding costs into the schedule to each individual task is a more accurate and detailed view, and then if work is rescheduled or delayed, the costs move too. However, you can get started with a simple spreadsheet where you phase the forecasted budget across the months of delivery and then record the actuals. You can do this as a practice exercise if you want to give it a go, even if you don’t have external costs. Resource costs are normally a huge chunk of budget, so if you are tracking time, you can match up how many hours/days were worked against the forecasted effort in the week/month and use that to phase the costs by activity. 2. Look for float Float is where a task has the ‘luxury’ of being able to start or finish later than the dates on the plan and not affect the critical path. Look out for the tasks with wiggle room – where you could let them slip a day or so or start them early and overall it has no impact on your ability to deliver to the agreed end date. Personally, I like to get ahead with those tasks because you never know when the resources or work might change later and you need that time for something else, for example a team member going off sick. However, some tasks are better done in a just-in-time way, so don’t bring forward those. You risk rework if you do something too early that might need to be changed later, even if there isn’t a formal task that would drive the change. For example, project communications can be drafted early but might need to change if the context changes, and if you are going through a transformation or strategic reset, the direction of travel might change mid-project causing you some more effort later. 3. Check in with stakeholders It should go without saying, but given that I’ve reviewed project plans created by the project manager with no input from the team when I’m mentoring project managers, I feel it does warrant a note – check your schedule with the stakeholders. I do create a high level overview with as much detail as I can before I share it with the rest of the team, because it saves time, and the alternative is having a giant workshop for planning. And frankly, we don’t have time for that (I know, I know…. The irony of not having the time to plan!). If we’ve had phone calls and conversations, there is probably enough I can glean from those to put together an outline and fit it to our project methodology. But the plan is not workable and achievable unless the key members of staff doing the work have signed off on it. A project schedule is a working document, so even when it has been around the team for discussion and refinement, it will need to be revised later on. |
Finished your schedule? Here’s what to do next
| Invalid hotlink: please upload your image instead. Tasks and dependencies? Check. Dates? Check. Owners? Check. But creating a schedule doesn’t stop when your Gantt chart has those elements in place. Even if it looks like it’s finished enough, you can go further to make your schedule really robust and useful for the project team. Here are 3 things to consider when you’ve got the bones of your project schedule together. 1. Find the critical pathI’m surprised at the number of project managers I work with who don’t use a critical path, but then, sometimes I don’t work it out either. The critical path isn’t helpful when there are lots of knowledge-based tasks with unknown durations and plenty of float. If most of your tasks can happen in parallel, or you have no fixed end date to aim for, then you could argue that it’s not super important to mark the critical path on the schedule. I think that the more experience a project manager has, the easier it is for us to spot the tasks that are critical or potential blockers to progress without having to highlight each one in red on a Gantt chart, but that also depends on the complexity of your plan. It’s easy enough to spot the path on a 3-month software development project, but I couldn’t work it out in my head on a 600-line ERP implementation plan. If hitting your dates is essential, and staying at the budgeted amount of resource is essential, and your plan is complex, then spend a bit of time working out the critical path. Normally you just have to hit a button to highlight it and then sense check what your software is telling you. Worth doing. 2. Work out the schedule riskLook at your schedule and risk assess it. Your software tool might have features to do this for you, or make some smart decisions about the kinds of risk your schedule presents and add them to your risk log. Estimate uncertainty and factor that in, especially if you are working with individual dates instead of ranges. 3. Level your resourcesA schedule is an academic exercise until you add in some people to do the work. And naming people against the tasks isn’t the same as working out if they have the capacity to actually do the work. The challenge with a lot of schedules in my experience is that they are not backed by a resource management tool, so it’s very easy to overload someone with activity across multiple projects. You don’t have visibility of what else they are working on, so you assign them to a task. When the time comes, they are fully occupied on a higher priority project, or they have to split their time. Resource allocation and levelling is tricky without resource management tools and when using duration-based planning. It might take me three weeks to get a new policy clause drafted and approved, but the actual effort involved is someone to write the clause (30 minutes) and then lots of time getting it through the approval cycles which involves small amounts of time from lots of different people. That scenario is hard to level and factor into a plan – especially when your subject matter experts can’t tell you which half a day they’ve got allocated to doing their work. However, give it a go. Sense check what you’ve got in the plan, look at how many tasks each individual has got allocated to them. Talk to them about their workloads and what else they are working on around the same time as this task is scheduled. As a minimum, factor in annual leave and vacation time! When you’ve got a rounded out schedule, you can baseline it and start working through the work. What else have I forgotten? Let me know what you do to keep your schedule a useful, working document, leave a comment below! |



