I continue to be amazed by how many software projects don't analyze the value proposition of the effort. In many cases, the only real value proposition documentation can be found in the business plan. Then, it only extends enough to ensure funding and the "go ahead" permission for the project. If the organization does a poor job of ranking project opportunities, the value proposition effort seems to become minimalistic.
If a project has to compete with other projects on laying out the value to the organization, then we have a ball game! Fierce project approval competition based upon the value argument can pay large dividends to an organization. If that fundamental effort is not done up front, then the professional business analyst should go back, research and document the value breakdown.
A number of years ago, I belonged to an organization and used to joke about the projects that were introduced by a particular director. I only joked about it a couple times during a lunch break and I quickly stopped once it looked like there might be a validation associated with it. The joke was that you could anticipate his next project submission based upon an article in the latest issue of Wired magazine. One day I was unfamiliar with some of the terms used in one of his submitted business cases. Then I discovered a couple whole sentences lifted out of a magazine article found via a Google search for one of the terms.
As I reflect on that experience, I have to give that director some kudos. I also have to be open to the fact that his project manager might have been the one to harvest the sentences, so there may not be direct traceability between magazine articles and this directors guidance of his domain. Even if the joke turned out to be accurate, that director would be basing his continuous improvement efforts on something tangible!
Back to the concept of value decomposition, the idea is that you can take any really big value concept for an organization and break it down into smaller ones. Value decomposition is a great way to tell which effort is based upon a strong background and which ones are more vanity based.
For example, lets say a project is proposed to do a Responsive Web Design update to an organizations web site. Is it a coincidence that Wired magazine had an article on it last month? Lets say this is indeed the case and it was the "Designing for a responsive web means starting with type first" article and not the "Responsive Design: The Boat-Car of the Internet". Side note, the later article has an awesome boat-car picture and I can totally see myself behind the wheel of that one.
You could build a decent value proposition breakdown from either article and RWD can have a strong value proposition to an organization. The other way to go is "the stupid pet trick" method where you show how a web page realigns itself when resized or shown on mobile devices. I have literally seen the stupid pet trick method used in a phase gate meeting and witnessed a project manager ask for funding becauseour lack of RWD cool was the reason why our web site visits are so low.
Value decomposition can be an EXTREMELY valuable effort for downstream phases such as requirements, technical designs and testing. If ignored for the "stupid pet trick" method, you loose all that value and potentially could be wasting a tremendous amount of time, money and resources.
© 2016 Dwayne Wright