.jpg)
The typical pitfalls and how to prepare for them
OK so now we know from part 1 - planning is hard and people can act against the best interest of the project.
What should we plan then? To what extent?
A Solid Plan by Kotarbiński
First off let us keep in mind features and qualities of a good plan.
There are 3 groups of qualities - Accuracy, Logical Framing and Utility Values.
Accuracy
- Purposefulness - are there adequate means mentioned to reach the goal
- Perspectiveness - Is it a long-term plan or a short-term patchworking?
- Strategicality - Not too detailed so there is wiggle room
Logical Framing
- Rationality - based on reality
- Completeness - leaving no gaps nor ambiguities
- Internal Consistency - so it is not contradictory in its different parts
Utility Values
- feasibility – consistency with earned experience, no fantasising
- operability – handiness and workability
- flexibility – a plan that is flexible, malleable, agile, and can be adjusted in the event of unpredictable circumstances,
- punctuality - so it can be time-bound.
- effectiveness – so the desired outcome is certain
This is what constitutes a good plan. I know that every reader of this article can bring up a plan from their past ( or present and future, matter of fact ) that lacked one or more of these qualities and resulted in ( or will result in ) a failure.
Some of those mistakes were made because the planners lack experience and knowledge about planning and some of them were made deliberately because of the negative stakeholders mentioned beforehand. The tool above is a good enough checklist to quickly verify whether the plan is success or failure oriented.
Let me now dig into how we can make a solid plan for problems mentioned throughout the article.
- Use already gathered knowledge on how to tame projects and products instead of depending on your instinct or lying to yourself that it will be fine.
- Consider using already existing IT project management methods and methodologies and apply it to your project.
- Assess how well you know the answer to “ What are we building?” and “How well do we know how to do it” and choose a corresponding method of decision making in the project.
- Pick a project management method or methodology that suits the level of uncertainty and learn about its advantages and disadvantages.
The solid plan could end right here as those methodologies are usually well thought through and offer solutions to usual problems. However bringing two opposites together and creating a hybrid model with pros only is a thought attractive enough for many.
The General Planning Pitfalls & what to do about them.
- Complication of complexity
As mentioned before, there are problems rooting in complexity of the software.
1. The increasing marginal cost of system maintenance and development - The pitfall that seems obvious and yet many fall into is to concept a non-maintainable or infeasible system and try to build it. It is of course a very broad topic and there are personas/stakeholders and coteries ( Death of Thousand Cuts coterie) interested in making others fall into those pitfalls and suck out money from the budget, this is why it is hard to be avoided without proper knowledge and experience as the goal might be presented as unambitious instead of infeasible. The way to avoid that pitfall is by applying the knowledge of IT project management and starting by creating simple systems that can grow overtime as its value and merits are verified in the real world. To be able to do that, one must think in phases and start off with Proof of Concept, Prototype, MVP and orientation of software development around the short feedback cycle of the end user.
2. Strictness of code language as a problem is big because it can also be downplayed by incompetent stakeholders as not as relevant as timing of the product. It is a pleasant simplification to trade off quality for better time-to-market and worry about quality later. It could be tamed from both sides - quality management that should tame lazy coding and the lazy scope requirements. For that proper quality assurance and quality control techniques should be applied - checklists, tests, scope construction templates, task creation templates, UAT, probing, Control Charts.
3. People involvement is probably the most problematic aspect as there is no permanent solution in this arms race. People and stakeholders have to be monitored as a part of stakeholder management activities in the project. I have linked above an interesting cheatsheet of archetypes that one should look for during the IT project turn of events.
- The chaos
Chaos in the project is an indirect consequence of not managing the project enough and can be a good idea from a perspective of an uneducated stakeholder that does not care for project success and can be kept in line only by following sets of rules that apply to the type of the situation the project is in - The Cynefin Matrix is a northern star to follow. Very chaotic IT projects can be tamed with short increments of value and a plan to bring about a much more organised approach of project execution by tighter management of project elements.
- The perspective
The project elements have to be identified and there are decisions to be made how they are going to be managed. As with every other element of this article, there will be narrations to put those discussions off or out by people who feed off bad projects.
The way to go with it is to have honest discussions with key stakeholders about the project elements/knowledge areas and agree to methods and techniques to tame them. Project management methodologies also come in handy but sometimes work as a repellent for stakeholders as they fear that the methods those methodologies offer might be improper or are afraid of structure in the project.
- The people
Understanding stakeholder management and difficult people is the starting point and one should be able to anticipate the reluctance of different stakeholders against planning and have counter arguments already… planned to convince them to plan nevertheless.
- Calendar Thinking vs Let’s Occupy Our Hands With Something Thinking
Understanding the difference of perspectives of different stakeholders and their approach towards the calendar and other project constraints is crucial and being able to explain expectations of one group to another. Psychology stuff.
- Unplanned work garbage bins
A big problem that can be countered differently but, in my experience, only a long-term approach with multiple methods applied is a working one. The recipe is to:
1. Make stakeholders understand negative effects of poorly planned work on examples (data, real-life cases, predictions on numbers).
2. Remind them about it from time to time as they plan to act out of line
3. Use a method/methodology that incorporates techniques to prevent scope creep or influx of poor scope requirements - from basic requirement templates to stricter change requests or functionality request procedures.
- The problem of complexity
The only working way to fight with dying or unpassed knowledge is to remember about Stacey Matrix so that there are optimal and suboptimal ways to manage a project in a given environment, propagate that knowledge, agree with key stakeholders on project methodology, inform people about why we use certain techniques, why there is no silver bullet and why there will never be, the pros and cons of every method.
- The Agile
I know it sounds hard but learn to detect “Agile” bullshit - any type of wishful thinking or presenting solutions without regard to their shortcomings should be an important cue.
Here’s a cheat sheet about the above.
How to prepare for Stakeholder management oriented towards planning work
One must start with identifying who will stir the pot in the project and identify their goals and expectations. By recapitulation - different stakeholders have different interests and thus will have different goals and expectations. Fortunately, it is possible to derive their approach towards planning as an activity and forecast their actions on it.
Project managers should formulate coalitions ( and break off other coalitions and coteries ) to be able to drive off any attempts at sabotaging the planning process.
Let’s take a look at default IT project stakeholders, their default interests, their approach towards the planning and what can we do about it - the table is enriched with difficult people in IT projects.
The Planning Pitfalls by Stakeholders
And here it is. You can use this knowledge to plan your own projects and be able to counteract planning obstructionists. I hope you find it helpful.
