Technology works best when it is focused on business solutions
 
Find The Why – Start a Project on the Right Foot

Find The Why – Start a Project on the Right Foot

One of the biggest weaknesses I experience when consulting on projects is a lack of why.  When the champion of the project is asked about the purpose of the project, there is an answer.  However, the answer is about a vision, not about solving a problem.  An ill-defined solution can be an issue for a project because having a cool idea is not the same as people needing a fresh idea to solve their problems.  We see this all the time with products that have a lot of fanfare but then fall flat on their face.  For those that remember the dot-com boom of the late nineties, there are several companies that fit this mold.  Pets.com went nowhere, and I remember a whole series of groceries on demand websites that never got beyond a memorable mascot or name.

More than an Idea

The key to any successful project is to have a sound reason why the result is needed.  I rarely come across a project where the solution is not necessary.

The disconnect is that the solution is not the focus.  It is not unlike a bill in Congress that starts out simple like “make X illegal” and ends up a thousand pages of riders and side projects that have nothing to do with the original goal.  When a project starts with well-defined goals that persist as the core requirements, then success is more likely.

 

Scope Creep is Deadly

Scope creep is such a misunderstood phrase.  The actual result is closer to an avalanche.  Each little variation from the core goals of the project can spawn other variations.  It is not uncommon to lose weeks of project implementation focused on features that were initially ignored.  It is important to define what a solution will not be.  However, the key to success is making sure that those “not in” features do not creep in later.

 

Think it Through

The easiest form of testing is to toss out a solution and have others dissect it.  The dissection should include stakeholders and end users in some fashion.  Although design by committee is not something I recommend, I do find that examining a solution in an open forum is highly likely to point out the flaws.  When you find the why of a project, follow up with an examination of alternatives.  Once you can communicate not only the “why” for a solution but also “why this solution” you are on your way to success.

 

Follow Through

Do not stop there.  Make the why of the project known to all the players.  There should be regular reviews of the requirements and plans to ensure that the why persists throughout.  When in doubt, you should always be able to tie a decision back to the why that started it all.

Leave a Reply