Pages

Friday, January 6, 2012

Software development and the Ferrari



Background
Corporate Bob occasionally delivers small parcels to satellite offices; and requested a permanent delivery solution from “Practical Solutions Department”.
“Practical Solutions” sent a business analyst to meet with Bob, so a proper solution can be provided.
Bob said… “Small packages, but speed is of importance; as these usually are legal documents to be signed as soon as possible”.
To meet Bob’s stated requirements… two fast Ferraris (second as a backup) were purchased later that month.



Problem
Now, what in the world is wrong with this scenario; Ferraris to deliver parcels.
Well for starters, a much cheaper car (or two) would have solved the problem too. 
But on the flip side, some may argue that the seconds-saved over a cheaper car is invaluable too.

Question is… 
How do we ensure that an optimal (whatever “optimal” means) solution is delivered? Not a product or service that is over engineered.


Analysis
Businesses constantly over engineer solutions… and there no proper gates or understanding to verify right fit.



To be practical… here are some potential options

  1. Always have a clear Vision/Scope statement; that is visible to all stakeholders.
    If you do not understand the original need, then you will not be able to understand if the solution is the right fit or not.
    By having the original purpose visible, we are hoping that somebody will start asking the crazy questions about the proposed solution.
     
  2. Stakeholder analysis: Identify stakeholders upfront. What each stakeholder role is and how to engage them.
    Recognizing and Publishing a stakeholder list will help identify the authority on various requirements.
    Knowing who has the final call will help in clearing noise… and in validating conflicting requirements.
    Stakeholder analysis will also stop random managers from requesting unintended features.
     
  3. Publish both raw-requirements and final-validated-requirements.
    Somebody will see errors in requirement interpretation.
     
  4. Make sure the business analyst actually understands true business needs; as opposed to what business said.
    If business analyst is not the business expert, then add a subject matter expert to work with the analyst.
    Business analyst is to represent true business needs to engineering… and to fight off crazy solution proposals from engineering.
     
  5. Investigate possible alternative solutions just for fun.
    Compare why the proposed solution is better than the other options. Write down comparison results for all to see.
    Come up with simple alternatives too… take a taxi, fax documents, use paper etc.
     
  6. Identify all costs that will take to maintain the solution over the years.
    (Licensing, installation, training, maintenance etc.)
    Don’t forget the long term support needs. Many projects concentrate mainly on delivering the solution… not on supporting activities, who and cost.
     
  7. Maintain an open feedback-list or a discussion forum.
    This will surface all concerns that get swept under the rug.
     
  8. Keep in mind that simplicity is still the king.
    If the solution cannot be explained in layman’s terms (conceptual design), that is the root of all Ferraris.