#4: Cramming Too Many Features into Version 1.0
It used to be that this was primarily a problem for interactive kiosk projects, however as more people add complex display software and interactive elements into their digital signage systems, it becomes increasingly relevant there as well. We've all heard the urban legend that 70% of technology projects fail (actually, depending on who is telling the story, it's 70% of IT projects, or 70% of computer projects, or 70% of software projects, but you get the point). Here's an article about it from InfoWorld, which is funny, because they also wrote another article about how that isn't in fact the case, but I digress... To be more specific, some large number of technology projects (but I would venture to say it also applies to projects that have nothing to do with tech as well) run into problems because their scope is never clearly defined. Project scope, as it is simply and succinctly described in Six Sigma terms, is the "defined and specific project beginning and end points. The more specific the details (what's in-scope and what's out of scope, the less a project may experience 'scope creep')." It sounds obvious, but a huge number of companies fail to adequately scope their projects before getting started with planning, sourcing, and the rest of it. That's why the very first thing that we do with new customers is to go over their project and see if there is a clear definition of its purpose, intent and limitations. Here are some of the questions that we typically ask. You'll note that while some of them are technical in nature, many have to do with the business side of things:
- What is the overall purpose of the network? Should it be providing customer service, lowering manpower costs, driving sales, or something else?
- What is the minimum amount of functionality needed to prove your business model?
- For each additional feature to be added (or implemented), what are the expected returns?
- For each additional feature that has already been added, did you get the returns that you were expecting?
- Is the primary focus of this project the trial deployment or the full system rollout?
- Has funding for the project been secured, or is it dependent upon the success of an initial trial?
- How will the network produce a return on investment? Will it be a transactional system (autonomous revenue generation), advertising supported, or something else?
- Is the purpose of the trial to test technology, customer comfort levels, receptiveness to different types of content, or something else?
- Can the network be rolled out in phases, or must it all be done at once?
- Can your software be upgraded in phases (which may necessitate the re-training of on-site staff), or does all of the functionality need to be deployed at once?
- Will you be responsible for the entire network end-to-end (including network connectivity, power, etc.), or just the kiosk and/or digital signage hardware?
- Has this project been requested by a client or potential client, or are you designing it ahead of time in hopes of selling it as a product or service offering?
- What things are you taking for your assumptions? For example, are you counting on signing some number of advertisers before you ever deploy your system? Do you need to have some number of deployment venues before your funding comes through?
Finally, you might want to consider putting together a formal scope document. These often take the form of an extended outline describing all of the parts of your system, and answering at least most of the questions listed above. While not typically used as legal documents, project scope documents can be thought of as a "contract" between all of the different parties involved, and if done properly, can help to highlight the strengths and weaknesses of your organization as your network gets deployed.
Comments
RSS feed for comments to this post