Introduction
In this multi part series, I’m going to uncover some of the aspects from my former life as a PRINCE2 project manager that I’ve carried over into Salesforce consulting. Coming from a waterfall background, I’m particularly sensitive to the areas where a stricter, more linear process would have benefited and I hope this series can bring the two worlds harmoniously together.
Prologue
Back in 2004, I was at Sheffield Hallam University in a lecture for the eBusiness module of my computing degree. At this point, I had no intention or desire to move into the IT project arena, it was just another topic along my four year journey to getting a bachelors degree. I had every intention in getting through university, collect my 2:1 and find an exciting job on the wild frontiers of a support desk.
Not much would change that career plan for a number of years, but something was taught to a crowed room in the Adsetts lecture theatre that stuck with me ever since.
The thing that stuck with me all those years was actually five words. Five vital words that should be applied to every undertaking, be it starting a business, implementing a new system or any kind of project.
The Five Questions
What, Why, When, How and Who. Rolls off the tongue with a nice bit of faux alliteration, but each word reveals a question, every one just as important as the next.
What
What is your quest? Or more accurately, what are you trying to deliver? It may seem like an easy thing to answer, but if you can only offer a high level sentence about the delivery, you’ve probably not thought about it enough.
Let’s say you’re implementing a timesheet solution. What are you delivering? A timesheet application? That’s a very high level way to put it. Chances are you’re actually going to be delivering a piece of configured software, a new business process, user training, project governance (eg progress reports… Probably) and any number of outputs from workshops along the way.
You’re not just delivering a single thing, it’s actually many pieces that all contribute to a combined output.
Why
Why are you delivering the project (What problem are you trying to solve)? This question would normally be answered in a project’s manifesto or PID. It’s important to know the goals of the project and why you’re delivering the “what” as it informs decisions during the lifecycle. This can be especially useful as you will often see projects several months into delivery with the original intention being just a distant memory.
Sticking with the timesheet solution, let’s imagine that a lightweight expense module is required. Something nice and simple, to support the star of the show, time logging. What if that timesheet module didn’t quite handle mileage the way the business does? It would be really easy to fall down a rabbit hole of day long workshops and heated discussions validating the solution. In some extreme circumstances, the whole application and project could be scrapped. All because a minor addition didn’t quite fit.
Keeping the “why” at the centre of every discussion ensures that the delivery is continually being steered towards the original intent.
When
Project plans are the best. They’re created once, the dates are agreed upon and they never change.
What a wonderful world that would be.
In reality, circumstances within a project change very frequently. Something may take longer than expected, another may be done quicker. People may get sick or get pulled onto a different piece of work. Life happens unfortunately.
That’s why a living plan is vital to a project. Everyone needs to know what is going to happen and when, especially if resourcing is involved – a subject I will touch upon shortly. Keeping everyone informed of the “when” reduces the risk of delays and ensures the stakeholders are given the latest status and their expectations are appropriately set.
How
One of the frequent casualties of Agile projects is the design, or the “how”.
It may be boring and time consuming, but every single project should have a high level architecture diagram and a detailed solution. The idea of documenting a solution isn’t new or innovative, in fact, it’s often forgotten about, especially on smaller pieces of work. But funnily enough, the smaller projects benefit just as much as the larger ones. This is especially true when a single person is doing everything. What would happen if that person became ill or decided to quit? If nothing is written down, the next unfortunate soul is going to have a impossible task carrying on the work.
Another benefit of documenting a solution is to help define best practice. If you’re carrying out a phased multi office rollout of a system, you can leverage the lessons and configuration of that first deployment. By keeping the design up to date, you can even possibly refine the rollout as you go along.
Who
This final question can in itself be broken down in a number of questions.
- Who is going to complete the design?
- Who is going to carry out the build/development?
- Who is going to QA test the product before it’s passed to the end user?
- Who is going to sign off the solution/user acceptance test?
Basically, if your project relies on the action of a person, and which project doesn’t – you need to know who that resource is. Knowing the resource can then tie back to some of the other questions. For example, once you know who is carrying out the build, you’ll need to know their general availability, for example if they have any upcoming annual leave.
So In Summary…
To increase your chances of a successful project, spend a few minutes at the very beginning to ensure you can answer each of the above questions. If you understand the what, why, when, how and who, you can take comfort in understanding the playing field a little bit more.
Considering the frequent shifts that projects see throughout their lifecycle, having a clearer picture can only help.