One of the biggest weaknesses I experience when consulting on projects is a lack of why. \u00a0When the champion of the project is asked about the purpose of the project, there is an answer. \u00a0However, the answer is about a vision, not about solving a problem. \u00a0An 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. \u00a0We see this all the time with products that have a lot of fanfare but then fall flat on their face. \u00a0For those that remember the dot-com boom of the late nineties, there are several\u00a0companies that fit this mold. \u00a0Pets.com went nowhere, and I remember a whole series of groceries on demand websites that never got beyond a memorable mascot or\u00a0name.<\/p>\n
<\/p>\n
The key to any successful project is to have a sound reason why the result is needed. \u00a0I rarely come across a project where the solution is not necessary.<\/p>\n
The disconnect is that the solution is not the focus. \u00a0It 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. \u00a0When a project starts with well-defined goals that persist as the core requirements, then success is more likely.<\/p>\n
<\/p>\n
Scope creep is such a misunderstood phrase. \u00a0The actual result is closer to an avalanche. \u00a0Each little variation from the core goals of the project can spawn other variations. \u00a0It is not uncommon to lose weeks of project implementation focused on features that were initially ignored. \u00a0It is important to define what a solution will not be. \u00a0However, the key to success is making sure that those “not in” features do not creep in later.<\/p>\n
<\/p>\n
The easiest form of testing is to toss out a solution and have others dissect it. \u00a0The dissection should include stakeholders and end users in some fashion. \u00a0Although design by\u00a0committee is not something I recommend, I do find that examining a solution in an open forum is highly likely to point out the flaws. \u00a0When you find the why of a project, follow up with an examination of alternatives. \u00a0Once you can communicate not only the “why” for a solution but also “why this solution” you are on your way to success.<\/p>\n
<\/p>\n
Do not stop there. \u00a0Make the why of the project known to all the players. \u00a0There should be regular reviews of the requirements and plans to ensure that the why persists throughout. \u00a0When in doubt, you should always be able to tie a decision back to the why that started it all.<\/p>\n","protected":false},"excerpt":{"rendered":"
One of the biggest weaknesses I experience when consulting on projects is a lack of why. \u00a0When the champion of the project is asked about the purpose of the project, there is an answer. \u00a0However, the answer is about a vision, not about solving a problem. \u00a0An ill-defined solution can be an issue for a […]<\/p>\n","protected":false},"author":1,"featured_media":70,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[8],"tags":[4,9],"class_list":["post-66","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-general","tag-best-practices","tag-projects"],"yoast_head":"\n