When “plan” is a four-letter word for tech projects

Should you be as committed to your project planning as you think you should? We debate the issues.
6 June 2022

Source: Nick Youngson. CC BY-SA 3.0, Pix4free

Every project, every new business strategy, and each and every aspect of an organization’s progress should, ideally, be planned, right? Not necessarily, and certainly not always. Having worked with over 500 technology companies of all shapes and sizes, from a two-person startup (albeit with millions in VC funding) to global multinationals, we think we’ve got a fairly experienced take on project planning in the technology sector.

Rolling out a new service, application, or fleet of containers to fulfill a need has to be achieved in an agile manner as quickly as is safe and practical. But there’s often an in-built assumption that every T needs to be crossed before a single line of code gets written. Many developers, for example, find that their best work is done by simply diving into a new project without giving too much thought to the big picture. There are always opportunities to refine or even start afresh, with many of those initial forays having answered issues that would be pure conjecture in an involved planning process.

But even with developers’ preferences to one side, here is our guide to the questions that business stakeholders need to ask themselves and their teams.

Question one: is it worth planning?
This question can be answered with pretty simple logic. If the total cost of your planning procedures is greater than the potential cost of failure, don’t bother to plan too much.

To expand on this, consider that most planning exercises involve meetings with various stakeholders, valuable hours (and processor cycles), putting together spreadsheets of potential outcomes, and so on. All this costs money and resources, especially the cost of your senior stakeholders’ time. Is it worth committing all those dollars to fairly simple projects?

Question two: are you bikeshedding?
Bikeshedding can be defined as talking and agonizing over every little detail of a project. Most small details will have little effect on eventual outcomes, so why waste more resources going through every eventuality? Stakeholders tend to contribute how edge cases might impact their department or people. If edge cases are unlikely, don’t talk about them.

Question three: Why are you being fair?
The most equitable and fair outcome isn’t the best in some cases – whether for staff, customers, stakeholders, or third parties. Being fair usually means things take longer to achieve, as every entity impacted needs to be investigated and questioned. A question like, “Whose outcomes are most pressing?” may yield a democratically sound and just direction for the company, but that path may not be the one that was intended. It certainly may not be the best way forward at all.

Question four: what else do your planners do?
There’s often a mismatch between who or what executes on a plan and who or what plans. In many organizations, middle-management tiers spring up whose remit is to plan for others to execute on. To ensure the continued survival of planners’ careers/departments, planning has to be continuous and ubiquitous. Planning, therefore, become valuable, but only to ensure a role or roles continue, not to increase the value given to the business by the planners.

Planning becomes what’s important, and it’s assumed the planning is difficult, execution simple. In technology, it’s usually the other way around. Execution of software development, system administration, infrastructure creation, and cyber security policy enforcement – these are the tough roles that take years of training and skill to achieve.

Conclusion
Planning can achieve better results than proceeding without any plan whatsoever. The key word is “better” – a comparative. The big question is how much better do you need your outcomes before the cost of planning outweighs the improvement or the cost of failure?