Kick off stakeholders: a checklist
Who do you consult when a project gets going? Or when you want to put forward an idea for a new project but need to run it past some key stakeholders? One issue I had on a project recently was that we didn’t involve our IT subject matter expert early enough. While that didn’t slow down the project, it did mean we’d made extra work for them, which isn’t kind, and I’m sure they felt like an afterthought, which is not the relationship I want to have with my stakeholders. So learning from that, here are some of the key stakeholder groups and subject matter expert teams that you should be talking to at the beginning of a new piece of work. ITLet’s put them first! Talk to your technical colleagues to find out if they can advise on the best solution. OperationsOperations are the group that keep the organisation working, so they run the day to day functions of your business. The teams are going to be different depending on what your business does, but they will know whether your project is going to have an impact on frontline staff and the operators. FinanceTalk to your finance team to find out whether there are any special requirements for this kind of project. For example, what are the funding options, how will financial benefits be tracked, whether contingency or management reserves are available and whether there will be a finance analyst available to support the work. They might be able to give you and idea of what budget is available in the portfolio which will help you scale the work. PMOTalk to the PMO about resourcing, scheduling and estimating and securing project resource. Generally, in my experience if you are the project manager involved at the start of a discovery or concept phase, then you’ll also be the one that carries on leading the work as it moves forward. But not always, so make sure if you need project support that you’ve got a PM and/or analyst assigned to the work and that they understand what is expected. Finally, don’t forget to include the senior leadership in your consultation. As a key stakeholder, they’ve got the power to say they don’t want the work to go ahead after all because something has changed. Equally, having their support for projects that are moving is invaluable because they’ll be able to support and champion from the top. Legal, compliance and data protectionI’ve bundled legal, compliance and data protection into one group but you probably have separate teams responsible for each function. Talk to each of the departments to make sure that your project is viable and meets with all the required regulations and policies. CommunicationsIf you have an internal comms team, talk to them about the project and what support you can expect from them. For example, they might be able to help with drafting project newsletters and briefings, and creating slides to share at leadership meetings. HRIf your project affects people’s jobs in any way, consult with your Human Resources team. There might need to be consideration given to job descriptions, recruitment, the onboarding and induction process, training and more. HR-related changes can take some time so it’s worth getting them involved early. Specialist teamsIf your project involves manufacturing, talk to them. If you need engineers, get input from them. If you have a big marketing expectation, bring the marketeers onboard at this point and get their thoughts. Work out what specialist subject matter expert teams are relevant to your work and include them. What other teams would you include by default? I’m sure there are some I’ve forgotten! |
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. 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. |
What’s on your go live project 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.
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 checklistTiming 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! |