There’s something that I’ve noticed over the course of my PhD studentship: I plan too much.
In my previous, commercial, career, this had worked well for me. When I was feeling bright and creative I would organise all the tasks that I needed to do, and make sure the prerequisites were in place, and then whenever the time was available – regardless of my state of mind – I could sit down and do the work. In the words of an old manager, “You like to line your tasks up, and then knock them down”.
Ducks in a row: less useful if ducks hold surprises. Photo: Flickr user jdhancock, licensed CC-BY 2.0.
That worked well then, because a large part of the work was technical rather than creative; I had to do things right, with good attention to detail, but once the overall concept was established the execution did not require me to be at my best. Perhaps surprisingly, I’ve had some success in doing academic writing the same way – I produce very detailed outlines, sometimes down to individual paragraph level, which is quite a fast process when I’m at my peak, and then find that I can write from them even when having an “off day”.
But that doesn’t work for research itself because, by definition, with research you don’t know what you will find, and hence you can’t always plan beyond the first set of results. In some recent work I planned out all the tests I’d like to do and the plots that I’d produce from that data… and my supervisor wisely said “see what the first set of data is like first”. That’s a pattern that I’ve repeated a few times in the last few years; I’ve planned far too far ahead, and then some unexpected results have made me throw that planning away.
Lining tasks up to knock them down is a useful technique, at least for me, but it isn’t useful for everything, and I need to develop some more diverse approaches.
This feels relevant: https://resources.workfront.com/project-management-blog/4-types-of-projects-which-kind-are-you-leading
Your approach works well for painting by numbers (which is how we’re taught to plan EVERYTHING) but not so well for the others.
Interesting post. Both the “fog” and “making a movie” types of project – neither of which has an objective – leave me asking “Why the hell are you doing this project at all?”. But I’m sure that doesn’t stop them from happening…
Fog tends to be “We’re in this pool of poo. We need to not be in the poo. We think up might be that way.” So What is “not be in the poo” and How could draining the poo, climbing out, building a raft etc.
Movie might be “we know how to build killer software apps. We need to find a new problem which we can solve with an all and monetise”
In fog cases the first thing you want to do is make it either a movie or a quest, ie choose what you’re doing, ou what approach you’re taking. (It’s rare to be able to do both, and if you can, the issue was with the skills of the people, not the problem itself.)
See also Cynefin and Wicked problems for thinking strands where well-behaved ducks are impossible or inappropriate.
(I get bored on anything where the How is known. Quests and Fog all the way for me!)
I guess these are more what I’d think of as scoping, rather than “projects” per se. But that’s just a question of terminology.
To give an example of a £30m+ fog project with clear scope:
“We’re replacing the following linked, bespoke, unsupportable, legacy software systems, and leaving these modern ones which talk to them alone. We have a cut-off date of X. We’ll buy in resource where needed.”
We didn’t know What the replacement looked like until we’d spent 6 months figuring out what it needed to do now and in the future rather than what it needed to do 10-30 years ago, and then designed a modern architecture. We would never know How to do it until w got started because it was a unique system of systems (“tender, buy, clean up old data, build & install, migrate data, configure software, test, train users” is How, but that’s about as much detail as was available until each previous step was finished and that’s so generic as to be useless)). Sure, it had enough similarities for those of us with experience to make informed estimates of how to do it, but the method was always going to be unique in its final form.
I guess you could call everything up to the design scoping, but it was a sufficiently long term and resource heavy piece of work that it came under project governance and thus needed an appropriate style of project management.
Hmm, fair enough – thanks.
Meant to add to first para: “not be in the poo” often isn’t the real What, it’s just the bit you need to do in order to do anything else. And sometimes, the way you thought was up, isn’t. Fog is all about small experimental steps and feedback before deciding the next step and direction.