How Not to Fit 12 Months Into 1 Month

Let's talk about the challenges of pilots or projects. One of the big challenges is avoiding the temptation to cram a year’s worth of work into a month. The idea isn't to rush through everything; you can't fit a year's workload into a month and expect to pilot it effectively. Instead, the focus should be on doing 10% of the work and delivering it to a small group of users. So, the key question is, what are we doing, and what are we not doing?

Running a project in this streamlined manner has significant benefits. You start the project more quickly by replacing old-school pre-funding activities with modern, lightweight controls that deliver more reliable results. You get immediate progress instead of waiting until the end of the project to see results. You also provide a better experience because you're developing it with users while the budget is being spent, rather than completing it and then presenting it to them. Ultimately, you realise a return on your investment throughout the project instead of hoping for benefits only after it's completed.

However, this new process does come with emotional hurdles for the IT team and delivery teams. One of the hardest things is shifting away from the traditional project mindset. This approach is fundamentally different, requiring a change in how we start and execute projects. The conventional method has been ingrained since the 1950s, making it a challenge to break away from it.

I've broken this down into three categories. First, there are activities we would typically do in a project that we just eliminate because they aren't necessary in this context. We have alternatives for managing without them. Secondly, there are preparations we must make before starting, which are crucial. Finally, there's a bunch of stuff we simply don't build. It's part of the pilot process—because it's a pilot, we don't need to build everything.