It’s time to bring out your inner Doc Brown and make your plan happen.
We can’t really help you build your thing though. The project manager’s job is to make sure the thing gets created, not to actually create the thing.
Many companies will specify that they want a Project Manager who is an expert in the thing that they’re building, and we don’t think that works.
The reason is, as a quality Project Manager, your job is to ask the so-called ‘stupid’ questions. It’s not to be an expert in the thing. If you’re an expert in the thing that you are building, you’ll have seen it many times before and perhaps the stupid questions won’t be stupid anymore. And then they don’t get asked.
Sometimes on smaller projects or in smaller organisations, it’ll often be the job of the Project Manager to wear two hats. The Project Manager hat and also the hat of the builder. So if you need to be both PM and work on a project, make sure you put yourself in the right mindset to get the job done.
You’ve worked hard to create a well thought out, fairly detailed plan.
Now you need to execute that plan and take it through the design, build, and test phases.
In your planning workshop, you all agreed who does what, when and how long it’ll take. And you’ve set up the relevant resources to design your end product.
Your experts now need the time allowed to turn the Sponsor’s words into a design or the Minimum Viable Product.
The key elements of Create are:
You will likely need to go through those 3 stages multiple times and refine until it meets all your requirements.
And it’s best to remember at this stage, version control. Just in case you want to go back to a previous iteration and allows you to keep your Stakeholders drip-fed with information as required. And it will remove the risk of overriding or losing your work.
You can either keep good version control manually or using an automatic tool. Manual would be to actually save the separate versions as version one, two etc. Whereas automatic would be using a tool such as SharePoint or Box which does it for you.
Remember your RACI. The more you can engage stakeholders along the way, the more likely you are to come to a successful outcome. You don’t want to put weeks of hard work in, only for someone to say they don’t like it.
And remember the concept of the minimum viable product. Somewhere between what you minimally require, and what’s sufficient for early adopters lives the MVP. The product that’s good enough to meet the core Why.
How do we know how good is good enough?
Remember the MVP and repeat the cycle.
Tweak as you go. Measure what matters. Improve and release more goodies every time you reveal your latest version.
That’s how you get there. It’s an iterative design process.
An iterative design process starts from the first stage and moves towards the last. Then the output is analysed, and more versions are run to improve it. Crucially, you test it with users or customers and go back to the Why. You also review the critical success factors and analyse differences in results and why the differences happened.
In this process, the goal is not to create a deliverable, but to improve the design in each iteration and keep adding value until you get there. You’re not trying to eat the elephant all at once.
This approach can also be great for team motivation. Teams feel more productive as they are delivering something quite frequently and can get responses on the produc. And they’re more likely to stay engaged in the process.
