Successful Projects Start with Good Discussions

How often does this ten-minute conversation happen …

Problem – Defined
Solution – Theorized
Owner – Identified 
Expectations – Set
Project – Go!

If we’re talking about a small amount of effort – perfect; I’m a great fan of focused action in manageable amounts. The challenge often comes when the Problem – Defined part goes too quickly – people may assume a challenge easily identified is just as easily solved.

Hopefully, the team can pause during the Solution – Theorized bit, and realize that this Problem could be bigger than a breadbox. In addition – someone should be asking the Value – Quantified question (“what’s the value in solving this particular Problem at this particular time?“).

Since folks like to call this type of non-recurring work a Project, we could try something crazy – like, applying some best practices from the world of Project Management. Don’t worry, I’m not advocating a fully leveled resource plan, with critical path tasks specified and scripted to the nth detail. Still, it might be a good idea to walk through the classic elements of a Project Charter to flesh out any big ideas from the Solution – Theorized step (“what are we doing, why are we doing it, who will do it, and when do we know that we are done?”.

Some other key things to think through …

• Requirements vs. Wish List: Know the difference between the essential must-haves and the merely nice-to-have. Unless, of course, there is unlimited budget and time available to get the work done …
• Time Box: You can always chunk the project up into smaller bites; what minimum subset would get tangible results and prove out the basic ideas? The more ambitious the effort, the more this approach makes sense.
• Don’t identify the Solution before you can define the Problem. if you think that implementing a New System will make things better, you aren’t solving a Problem – you are turning on a Shiny New Thing.
• Don’t engage vendors and ask for detailed bids unless you know you have the Budget. It’s ok to ask for rough-order-of-magnitude estimates, to help get the budget approved; you can triangulate in on the right cost / scope without burning a ton of cycles on detail work.
• Define Success before you start – something measurable and tangible. Note that milestones (such as “new system is in production” are not the best Success metrics. Try “first month of shipments with zero customer issues reported”, that’s a much better indication of Success.
• When building the budget, make sure you consider Total Cost of Implementation + Total Cost of Ownership. For example – that large software purchase you are cleverly negotiating will require a raft of servers to run on. Any data-driven process will require ongoing data quality and maintenance – is there a clear and specific plan for who will have these incremental tasks added to their normal workload? And, if you are adding new work to an already fully engaged person – are you taking other work off their plate to compensate?

Even in the overhyped world of technology, these non-technical issues (resources, cost, time, priorities) are often the root cause of project difficulty and failure. Talking things out up front can save a lot of headaches and disappointment later.