Tech_Projects by panniuniu


									Technology Projects –
Why are they so hard?
The Big Picture is Ignored

   Technology does not exist in a
    vacuum – what is the business case
    for the project?

        Organization              Technology

Selling the Invisible

   Users cannot imagine or
    understand what is needed until
    they see it
   Management cannot understand
    why it costs so much
   Difficult to measure value of an
    invisible product
          Expectations are

   Users don‟t understand the complexity of writing
   Technology often seen as a „silver bullet‟ by
   Unpredictability is the norm – machines often
    don‟t behave as we expect
   Programmers tend to underestimate time to
   Requirements are mostly not clear at the
    beginning of the project
        “Wicked Problem”

   The problem is not understood until
    after you start solving it.
   No one defines the problem in the
    same way.
   Constraints and resources to solve
    the problem change over time.
   The problem is never solved.
         Beware Unintended

   Mythical Man-Month
Planning helps…

 “Plans are the successfully delivering the
       value defined by the customers

There are many Planning Methodologies…
    Other Life Cycle Models

   Incremental Build
   Rapid Prototyping
   Rapid Application Development
   Extreme Programming (XP)
Improving Success Rates

   Understand how IT serves the overall business
   Create documents, flowcharts and other
    physical artifacts that help the user understand
    what you are proposing. Attach detailed cost
    estimates for management that include ROI or
    other financial information
   Develop specific measures of value for your
    project with by establishing baselines
   Ensure that the problem to be solved is actually
    a technology problem
   Prepare your users for the “unknown
    unknowns” – machines do not always behave as
   Double or triple time estimates from
    programmers – they never include debugging in
    their estimates
   Document, document, document. Requirements
    will change – document the original spec and all
    subsequent changes
   Learn to identify the Wicked
    Problem and think carefully about
    unintended consequences
   Planning helps – pick a
    methodology, train your team to it
    and be consistent with it. What
    works best varies by team and size
    of project.

To top