This week in pm-clinic: Plan for the plan
This week in the pm-clinic discussion forum– Plan for the plan:
I work at a near v1 release start-up – we’re mostly industry vets who’ve worked together before, but we’re growing fast (7 new hires in the last month – 20% of our staff).
Some of us feel we need to write down something about how we do what we do – style guide for code, an outline for how feature decisions get made, you know – high level process stuff. It can be short and sweet, but we need a reference point.
Others feel it’s a waste of time, it never helps, and we should just be figuring it out as we go. No need to be all goody-too-shoes and orderly: we’re smart enough, as a small org, to work tight without documenting foofy things like processes.
How do you know when you need a plan for the plan? Who should write it? And how do you do it, especially for small anti-process teams, so that it’s beneficial in some way?
– Considering a plan for the plan
At my previous place where people never knew about software engineering and processes for product development, a written plan was necessary given the kind of mess it was.
However, in this situation where people already know good processes, a plan could simply be a collection of documents or even links to documents indexed off the internet or books.
As simple as that. It should be a reference and not the final word.
Good point, Vineet. I think it’s a good idea to outline general principles, especially if you are in the throes of growing pains. Two issues to consider: 1) the degree of detail to which you document will be a function of the maturity of the group. If you have a professionally mature group that speaks the same language, keep the documentation to a minimum (single page). 2) watch how you “sell” the concept. Parameters, guidelines, and frameworks go over better than policies, procedures, and plans. It’s all in how you spin it.
Even Da Vinci had a plan, and he worked alone.
Everyone has a plan for their contribution to the project, and that specifically, is the problem: so many people = so many plans.
Each perspective on the problem (read, “individual contributor’s plan) is framed against a different background of experience and knowledge. Where the contributions i.e. tasks overlap, so too will the perspectives. The integration of perspectives requires communication. Sometimes it is sufficient to chat. More often, proximity, ego or politics prevent meaningful chat and if circumstances are ripe, might even stop progress altogether (which means actually stop, or proceed surreptitiously, which is the leading cause of imbroglio).
It seems that the degree of plan formalism required must be based on the realistic assessment of the “interpersonal thermodynamics” of the project space. To whit, the 2nd law of entropy – the trend to disorder, must be well considered.
What factors influence?
The greater the complexity of the project, the more profound even subtle differences in individual perspective.
The greater the number of people the lower the resolution of the problem domain; that is, with more people the problem domain itself must be blown up incrementally in order for everyone to see it: this reduces the clarity with which the project “team” as a whole might view the overall picture (pardon the play on words, but dispute resolution is also at issue).
The conclusion?
Realistic assessment and a process that scales in formality as necessary.