This month Pete Doyle, our Head of Transforming, is looking at what could go wrong when managing a project.
Many years ago, I attended a course on managing projects. At the time as a “techie”, it certainly opened my eyes to the world of project management and whilst I recall it covered all the usual topics you’d expect, one quote has stayed with me ever since:
“The plan is nothing, to plan is everything”
So what does that mean in terms of ERP projects? Having implemented far too many ERP systems than I care to remember, what I have found to be a common theme throughout is a beautifully crafted and often extensive project plan. Filled with all manner of complex work breakdown structures with phases, activities, tasks and subtasks, enough dependencies to last a lifetime and let’s have plenty of resources in there too. However, this is just what it says – a plan. Unless it is fit for purpose and can be easily shared and maintained, then often it can be central to the reason projects fail. Too often I’ve been handed a very large file which if printed might consume a full ream of paper and although it might be comprehensive as a list of “what we’ve got to do”, is unusable as a day to day device to effectively manage the project to a successful conclusion.
So what’s the alternative? Well given my quote above, for me the planning tool used is less important than the process you follow.
So here are my tips for simpler and I believe more useful planning:
-
Start with the big picture
Sketch out in simple terms the major project phases, as rough as you like and then start to add your timeline. In a few cases you may already need to adhere to an essential completion date set by your client, but generally, I’d recommend you need to confirm what needs doing before you can think about an end date.
-
Who do I need to consider when planning?
So now you’ve defined some phases, make sure you’re clear on who are your stakeholders, both internally and externally. I often see a major assumption made that colleagues or clients can just ignore their day to day duties to work on the project as and when required. Likewise, in ERP implementations, there will usually be a solution vendor or their partner involved, who just like you will have other commitments. Lovely as it would be to think you are their only client project, in reality, they will be juggling their time and resources like any business – in fact, begin to worry if that’s not the case!
-
Dive into the detail
Next comes reviewing each phase and adding activities and tasks. Be careful here not to overcomplicate matters – remember your intention is to be able to manage down to the right level but not so deeply that you’re in danger of having to micromanage and report on every single action. It’s likely here you will need to engage with stakeholders on all sides so that your plan is neither a statement of work from your vendor nor only a list of what your colleagues need to do.
-
Consider dependencies
Often, I see plans that are so complex that it’s difficult at first, second and even third glance to understand how they work and what they are trying to represent. So whilst it’s obviously important to know for example which tasks can’t start until others are complete, I’d urge you to keep this really simple. In most ERP projects, good project management means dependencies will be understood, communicated and managed as a given, so just make sure where these are needed, they are documented and reflected by the plan.
-
Who’s going to be doing the work?
Build a simple list of who is going to be directly working on the project, either at a functional level or down to individuals, depending on how much granularity is needed. For many ERP implementations there should be no need to worry about project time booking and costs of allocated resources, at least not as part of the overall project plan. Yes, it is important to measure and manage all implementation costs, but no, this doesn’t mean you need to rely on overly complex time recording by everyone who is engaged in project activities. A good start is to discuss this with the finance team to align with their expectations on accounting for project costs.
-
Assign resources
Do this by phase and work through your required tasks. I also find it useful to clarify internal vs external assignments as it then becomes much easier to filter when I’m looking at who I need to chase to assess progress. Where possible, try to assign an owner to each of your tasks, then it’s far easier to engage with the owners as the project gets underway and to ensure they are bought in and remain on track.
-
Set the timeline
Only now can you fully map what needs doing to a realistic timeline. My adage is that it’s always better to implement a working solution once it is ready than a solution with bugs or issues, just to hit an arbitrary date. So look ahead, clarify any blackout periods (holidays, key events, shutdowns) that may help or hinder the project and only then set your start and end dates for each phase. Don’t forget to allow some all important contingency – not just time, but also across resources and costs.
-
Validate and then share your plan
The baseline project plan is your starting point but needs proper validation before it is shared with a wider audience. This is likely to involve seeking the views of the key stakeholders, your project sponsor(s) and perhaps your own colleagues to double check nothing obvious has been missed. Only then should you share the plan – this can be in a number of ways, perhaps a presentation to the project board, a call or meeting with the core project team and one to one meetings with other key stakeholders.
And finally
So there we have some of the basics of preparing a realistic plan that represents what needs to happen and when. Once you’ve created the baseline, the plan must be dynamic as time goes on and tasks get underway. Don’t be afraid to replan regularly but most importantly make sure all involved can easily see the progress and the impact of any changes to the baseline. I’ve seen so many complex plans that are only visible to the Project Manager, so think about how you can easily share your summary of the plan and progress against it, without the need to equip all concerned with complex tools or for them to spend hours trying to interpret where things are at.
One burning question remains – which tool should I use to create and maintain my plan? Well, the answer as you might expect is whatever works best for your project. You may be bound by your client to use sophisticated tools to support very complex and lengthy projects – so Microsoft Project can be your first choice. However, for the more regular, routine ERP implementations, any tool which helps you build a clear, concise and shareable plan will do the job. Personally, my need is twofold. Firstly to manage the day to day tasks which can often be supported by Microsoft Excel or Google Sheets. Secondly, anything that gives me a high level, graphical representation that I can share with senior management who don’t really need all the detail – here there are a myriad of really nice tools that can do the job.
So there you have it, nothing new really, but I hope just a useful checklist and approach to help you avoid project failures by planning to succeed in the first instance.
If you are looking for some extra support with your project, why not get in touch?