Project Management

The Money Files

by
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from RebelsGuideToPM.com.

About this Blog

RSS

Recent Posts

Spring clean your portfolio: Setting clear priorities and roadmapping

Spring clean your portfolio: Resource management

Spring clean your portfolio: Portfolio review

3 Types of programme cost (that are not project costs)

How to keep a business case up to date

Categories

accounting, agile, ai, appraisals, Artificial Intelligence, audit, Benchmarking, benefits, Benefits Management, Benefits Realization, books, budget, Business Case, business case, carnival, case study, Change Management, checklist, collaboration tools, communication, competition, complex projects, config management, consultancy, contingency, contracts, corporate finance, Cost, cost, cost management, credit crunch, CRM, data, debate, delegating, digite, earned value, Energy and Utilities, Estimating, events, FAQ, financial management, forecasting, future, GDPR, general, Goals, green, Human Resources PM, insurance, interviews, it, IT Strategy, Leadership, measuring performance, merger, methods, metrics, multiple projects, negotiating, news, Olympics, organization, outsourcing, personal finance, pmi, PMO, portfolio management, Portfolios (PPM), presentations, process, procurement, productivity, Program Management, project closure, project data, project delivery, project testing, prototyping, qualifications, quality, Quarterly Review, records, recruitment, reports, requirements, research, resilience, resources, Risk, risk, ROI, salaries, Scheduling, scope, small projects, social media, software, Stakeholder, stakeholders, success factors, supplier management, team, Teams, Time, timesheets, tips, training, transparency, trends, value management, vendors, video, virtual teams, workflow

Date

More schedule tasks to do before you baseline

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.

tasks for 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.

Posted on: April 10, 2024 02:43 PM | Permalink | Comments (5)

What’s on your go live project checklist?

go live checklist

Every project needs a go live project checklist – at least, projects where there is a substantial ‘go live’ moment, like a software launch.

The checklist is helpful because it confirms what is needed to go live: the steps and actions that should have been completed. It’s a reminder of what work is required in the run up to the big launch – or the small launch if you’re doing things in a phased or incremental way.

I’m a big fan of go live checklists because they help take the emotion out of the decision about whether or not we are ready. If we have ticked all the boxes, we’re ready. It makes the go/no go call very straightforward.

Here are some typical things to include on a checklist, although bear in mind that every project is different and you’ll need to make sure the items on your list match what it is you are doing.

  • Technical infrastructure in place for the production environment
  • Adequate staffing in place and critical staff available, taking into account holidays and sickness etc – too many people off and we might delay the launch until they are back
  • Support teams and helpdesk briefed
  • Go live plan produced and circulated
  • Business acceptance testing complete
  • Contact list created and circulated
  • Communications about the launch drafted and approved
  • Major risks reviewed and a decision taken about whether any of them are substantive enough to affect the plans.

We would also book a go live meeting. I remember one call we had for a big software pilot and going round the (virtual) table and asking each workstream leader to say ‘yes’ or ‘no’ depending on whether they felt the go live criteria had been met. It was a challenging call, because while we had on paper met the criteria, things were still a bit wobbly.

These conversations give you a chance to get all stakeholders on the same page about whether to go or not, and that’s helpful for creating a shared sense of responsibility as soon as you make the decision to get started!

I’ve noticed a trend towards incremental delivery and smaller launches, even on projects using a predictive methodology. There is still a place for a go live checklist, because getting everyone together to make a joint decision about next steps is still valuable. It’s the opportunity to get sign off on the approach and next steps from the business representatives, IT representatives, vendor, sponsor and anyone else who has an interest in what happens next.

When to use a checklist

Timing your go live is really important for maximum impact and availability of support staff. For example, we would never put an IT system live on a Friday as there would not be enough project team members around over the weekend in case of issues. We would put software changes in overnight, and have enough staff around in the morning to monitor the system and deal with any unforeseen issues.

Think about when you are going to have your go/no go call and when your go live is going to happen. The call itself needs to be close to the go live but probably not the same day, for example it would work well to have a call on a Friday for a Monday go live, or a Tuesday for a Thursday go live. But look at your schedule, consider the impact on users and make a decision as a team.

Do you use go live checklists? What other items would you put on a generic checklist? Let me know in the comments below and save this post so you can come back to it when you need it!

Posted on: June 20, 2023 08:00 AM | Permalink | Comments (9)
ADVERTISEMENTS

"There is more to life than increasing its speed."

- Mahatma Gandhi

ADVERTISEMENT

Sponsors