There is no Plan A!

There is no Plan A!

• Daishik
• 27 May 2022
• 2  

In our previous article, we started to consider how your company or team might shortcut conventional wisdom in an effort to deliver projects faster and at lower cost.

In this article I want to address the problem of planning and how you can effectively 'cut straight to the action'. Who needs all that bureaucracy, those incessant meetings, documents and communication?

You want people to stop talking and start doing!

Dealing with complexity

Sometimes the complexity and duration of a piece of work can be difficult to judge from the outset.

Software projects involving legacy systems, or integration of new or unknown external systems can be particularly difficult to estimate. Analysis and preparation help of course, but in many cases, like a bathroom renovation, you'll only see what needs doing after you start stripping away the façade.

Some might argue that whether a bathroom or a software revamp, such difficulty doesn't preclude the need for structure and planning.  It is possible - and indeed necessary - to prioritise, make estimates, identify milestones and, issues, prepare contingencies, consider mitigations, and of course, limit the scope of the project.

They may argue that in fact the less you know about a system or process, the fewer the people in whom the critical knowledge is concentrated, the more discussion there needs to be about it, and the more planning and contingency is necessary!

But let's face it, as a unique business you don't need to entertain such quibbles!  Leave aside Plan B, some teams don't even bother with Plan A!  Let's find out how you can do the same.

Skip the planning

The problem with planning is that plans can become too rigid and regimental. After all, your business demands flexibility, dynamism and adaptability! You're supposed to be agile* aren't you?

What you want is to be able to quickly react to changes, make changes, change them back again, move people around, reprioritise and change requirements at any time for any reason. It's not important to you that people know what they are doing from one day to the next, let alone understand what is happening next week.  

You don't want your team to focus on A now, then B, then C in a few weeks time.  You want them to work on A, B, and C NOW!  And switch to D, E and F if you change your mind.

The problem you may face is that most teams generally like to know what they should be working on. They want to understand what they'll be working on in the near future so they can manage their own time and coordinate activities with colleagues. Furthermore, you may have no choice but to show senior management something that looks like a plan. 

You don't have to succumb to this.

If you must have a 'show plan', a useful strategy is to do what I call 'simulated planning'.  You hold planning meetings but nothing specific is actually planned, or if it is, you have no real intent to stick to the plan. 

For example, a recent client regularly held team planning sessions. The only focus was on elapsed time - did the developers have enough work to fill the time between this session and the next?  The 'plan' was to fill the available hours with tasks, most off which were poorly defined. The tasks were freely moveable on a whim, with little prioritisation or triage, and if a task took more time, it was just carried forward to next 'planning' session.  The key thing was that Joe the developer had enough to do between this planning session and the next.

Did the fact that Joe’s time was filled throughout this period imply that he was delivering outcomes that produced business value or that met the project goals? Sometimes they did, but just as often, they did not. 

Nevertheless, the majority of the team members were satisfied with those sessions (in fact, most just ignored the outcome).  Either way, the simulated planning session ticked the box.

A different client focused solely on targets. They considered 'planning' to be the act of informing the team of milestones or the deadline, based on arbitrary dates or sales targets. With the pressure on right from go, the team flew headlong into a mad rush to deliver something without any 'time-wasting' discussion, analysis or clarity.  For them, it didn't matter that Joe only had X hours - he had to complete all tasks allocated - even if many of those tasks were never defined and in some cases, even considered.

Here too, the simulated planning sufficed for ticking the 'planning' box - there was a goal and the 'plan' was to deliver it. The details could be worked out along the way. 

Rip up the plan

But what if you're in an organisation or team that simply must work within a formal plan and 'simulated planning' won't cut it.  Nevertheless you really want to 'cut straight to the action', tear up the rulebook, etc etc.

You need to be able to disrupt the plan, and for this a middle manager - someone who sits between you and the professionals doing the work - is your greatest asset. I frequently see weak middle managers step up and sabotage the very team for whom they are responsible.

How can you do this?  At the individual and team level, the team may be hell-bent on delivering according to their plan; communicating, prioritising, allocating resource, defining scopes and working towards the planned goals.

Your manager must be the type who will easily and regularly capitulate to 'urgent' edicts from you/senior management. They will re-assign team members, re-prioritise or introduce new tasks or change goals, and thus upend any prior plan. 

In some organisations this is norm: the middle manager is almost entirely an instrument of disruption rather than facilitation. Over time, the team loses hope of ever following a plan and eventually the process of planning becomes moot. You can then gleefully shift to 'simulated planning', or even abandon all semblance of planning completely!

The risks

Although companies do survive - and often succeed  - without planning, you should be aware that there may be consequences.

In my experience, cutting out effective planning always results  in one or more of

• poor level of analysis and understanding
• lower code quality
• reduced testing and quality assurance
• increased technical debt
• high levels of team stress

From your perspective as a business leader these may translate to 

• major revisions and re-development late in the process (with potential cost implications)
• changes to user journey and UX (with knock-on effects on training and documentation - and potential cost implications)
• more rounds of late testing (yeah, cost implications)
• delays to other features and tasks on the team’s workstream (cost... you get the idea)
• more complexity in the code base, raised potential for bugs, increased difficulty when implementing future features
• problems on delivery such as difficulties in deployment, integration, and issues on cut-over/launch (implications for cost and reputational damage)

So how do low-plan or zero-plan organisations “get away with it”? I'll explore that in a future post.  Next up though, we’ll look at analysis.

* No you're not!  To learn about actual Agile methodology start here.

Click on the links below for the other articles in this series

• Tearing up the rulebook - We know our business is unique, so let's just tear up the rules and do everything in our own, unique way!
• Analyse this! - A popular shortcut is to leap over the analysis phase, with the hope that issues will be easily resolved during implementation
• Testing times - Another favourite! Shortcuts on testing and quality assurance is a great choice if you're keen to cut back on cost, resource and time
• Getting away with it - So you've cut corners and played fast and loose with best practices. Here's how you can still succeed in spite of the consequences!
• The gods among us - The ultimate, and most effective solution to managing the fallout from shortcuts. But there is a price to pay!