When a project needs a specialty tower I've never dealt with before, I like to find out what questions I should be asking. The key to relevance is to ask them from the person who is the expert from that specialty tower.
I ask "Since I'm new to this, what are the types of questions I should be asking others in order to get to you information that makes sense to your group?"
?
If there are two possible courses of action that present themselves to a situation, I’m fairly comfortable making a decision and sticking with it. I can accept the fact that if I’m wrong I will have to live with the consequences. Most of the time that’s the normal course of daily business.
However there are occasional situations in managing a project when my intuition wants to fight my intellect. That’s when my intuition is against taking any course of action at all, the facts not-withstanding. When that happens, I do make an effort to side with my intuition. I admit it’s not always an easy matter for me. My preference is for action, decisive action preferably, but some kind of action at the very least.
There are times, when after I’ve circled the same hole around over and over with all the supporting and opposing arguments, I realize my intuition says I better just lay low on this one and wait. Simply wait. I don’t know what exactly I’m waiting for, but more often than not, when I get that intuitive feeling it usually is for the best. The waiting in those cases, has a way of mysteriously removing obstacles through no action of my own. Wow!
Sometimes, just...
Don’t Do It!
The other day, as I sometimes do, I was laying down next to my 3 year old on the bottom bunk to encourage him to fall asleep. When I do, that’s when my own mind starts drifting off and wandering into the zone of great ideas and thoughts (well, sometimes I just fall asleep).
I was fooling around with my cell phone trying to understand some of the more obscure settings on it when I suddenly realized how much the bars of the bunk-bed reminded me of project management. The bars appear to fade together the further in distance they are, even though they are in fact equally spaced. The bars closest to me in contrast are very spatially distinct to my mind’s eye. Hey, I thought, if each one of those bars were tagged with a milestone or deadline, then the principle of Agile Project Management would also echo the visual perception of objects in the distance. The closer in time something is to occur, the principle of Agile says, then the more distinction in definition and purpose an event should be given. The further out in time, the less granular and more fuzzy the planning should be.
So I took a pic of the underside of the bunk-bed with my cell phone and managed to upload it here for your enjoyment.
Black-Boxes, Cog-Wheels, Inside & Outside Circles, and PROCESS CYCLE TIME.
I’ve been training myself to think in terms of “process-cycle time” instead of “work-effort hours”.
Say I know for a fact that a particular database coding task really only takes about 1 to 2 hours to accomplish on average in the hands of a dedicated technician. So do I use the 2 hours estimate in my plans? No. While it is true that the actual work time has meaning to the technician doing the task, it has very little project management use. It’s because the 2 hours of actual task is not the real turn-around time to get the job done.
What I want to really know is how long does it take for the request to go into the black-box of the programming team and then come back out of that same black-box all cooked and ready for consumption.
Sometimes I don’t want to even know the details, but here’s what I would suspect is happening inside the black-box and cog-wheels of that fictional team:
Code work request gets submitted (e.g. 2 minutes)
sits waiting (e.g. 1 business day),
gets reviewed (e.g. 5 minutes of scanning by an expert),
sits waiting some more (e.g. 1 business day),
gets approved (e.g. 1 minute),
gets scheduled (e.g. 10 minutes),
sits waiting some more (e.g. 2 days)
actually gets coded (e.g. 2 hours),
then gets submitted, reviewed, corrected, and then finally accepted and proclaimed as task done.
In that case the turn-around time I’m looking at is about 5 to 7 business days. That’s the time information that’s relevant to making plans and setting expectations with the customer.
(Incidentally, you might have noticed that doubling or tripling the speed of the coder would actually have little effect on the cycle-time – the gains could only be obtained in that department by improving its internal process.)
What do you do when you are dumped with stacks and stacks of documents? How do you take control of that flood of information so you can distill it into a sensible overview?
As a Project Manager, I depend on the input of dozens of specialized functional groups, each with their own jargon that I need to decipher and translate into meaningful points of reference on a map to get the “big picture.” They are very detailed and very specific. It’s a mistake to tackle it with the same level of granularity. You will feel completely helpless and exhausted if you try that maneuver. Instead you want to go the opposite direction: go real simple.
First: Get a roll of white butcher paper, one roll of masking tape, and about three colored felt pens. Tape large sheets of the butcher paper onto any free space you can find on your office walls.
Second: Print all the docs that were given to you. Your printer will probably go for an hour just churning out all the legal docs, requirements, memos, Statement of Works, specs, etc.
Third: Grab the top document from your freshly printed stack and doc by doc, page by page, read at fast clip. As you’re doing this, write all the questions that come to your mind somewhere on one of the wall charts. Summarize major points and facts onto the wall chart. Go back to earlier questions on the wall charts and mark the answers to them as you discover them.
Tip: Switch color felt pens so it is easy to see the different points you are putting all over the wall charts. Group thoughts by areas on the wall chart if you so desire, but don’t even do that if you find it is slowing you down. Watch the clock so you can race yourself to the end of the stack. Sketch quickie charts & flow-paths if the mood strikes you, but keep moving.
Done! You now have the big picture.
