Thursday, March 29, 2012

Right questions, wrong time.

Not too long ago, one of the functions for my role was to identify deficiencies, research high level solutions and propose it to the IT upper management. These were often turned in to projects. This steering committee of directors, programme managers and, on occasion, the CIO was the Tech Council, affectionally referred to, by those of us who presented to them, as the Dragon's Den.

One reason I couldn't get sign-off on the first shot was because I would be asked questions I didn't immediately know the answer to. I'd promise to investigate and return next week with the answer.  The next week, I'd have an updated deck with new slides answering the questions from the week before. Then, I'd get more questions I didn't have the answers to.  Their concerns were absolutely critical for the project to be successful.  But were they being asked at the right time?  These were 'how' questions.  'How are we going to back it up?', 'How will we mitigate this?', 'What will our support strategy be?'.

Once a project plan is created and resources are allocated, there are obvious times to ask these questions, and people to whom they should be asked.  Is there a business justification? and is it possible? Are the only things that matter to determine if a project is justified.  Asking how type questions this early is a form of death by delay.  There's a reason something needs to be a project, it's going to take time and resources to answer all of these questions.

So, rather than fetching the answer prematurely.  We all would have better served, if we recognized it wasn't the right time.  I should have answered their questions with a question:  "Of course we will need a backup strategy, but is there any reason to expect the project team won't be able to devise one?".  I can count on one hand the number of times I've seen a problem that the team was unable to solve or circumvent.