Live from WBF 2008-- The Zen of Project Management

Three Principles for Reducing the Time It Takes to Implement Software Systems John Roach, Senior System Architect, Advanced Automation Three Principles: To Speed Up, Slow Down
Use Iterations To Increase Perceived Speed
Brace for Impact
Here's an illustration. It's called the Rock Problem. You're providing rocks. I would like you to build for me a rock. No, that's not the one I had in mind. I want one that is blue. No, that's not what I had in mind. I'd like something smaller and round. OK, a small, round blue rock. I look at you like you have three heads. That's not what I want. We're not speaking the same language. WHATTTT???? Well, what I want is a blue, cats-eye marble. To speed up, slow down. Don’t be in a rush to start writing code Take the time to perform a thorough requirements analysis Applies to custom, semi-custom, and off-the-shelf. Keep the solution out of the process Use diagrams and models The type of diagram depends on your audience What types of diagrams? Engineers: Physical models State Models Procedural Model Process Model What types of diagrams? End Users: UML Use Case Diagrams Activity or Flow Diagrams Sequence Diagrams Paint pictures for your end users Gives them an idea of what their user experience will be Use the diagrams to make technology decisions What is the best fit? Custom, semi-custom, or off-the-shelf Set up evaluation checkpoints Where is the requirement analysis taking me? Keep the diagrams up to date! Use Case Diagrams help with test plans Activity Diagrams help with test scripts Use Iterations To Increase Perceived Speed Implementing Software Is Iterative: Requirements-->Analyze, Design, Code, Test-->>Deployment Advantages: Implement core functionality in a relatively short timeframe You receive end user feedback The pressure to be perfect the first time is diminished Time consuming features don’t hold up implementation What Comes First? Risk Do a risk assessment High risk items should be implemented sooner Interdependencies Implement functions earlier where there are other requirements that use it. Group functions together that are interdependent What Comes First? End User Priority Requirements with strong demand Have to have vs. nice to have Return on Investment (ROI) Inexpensive with high ROI first Expensive or lower ROI later…or never? Base the project plan on iterations Each iteration produces working code. Start with the most important features and get them deployed. Each subsequent iteration adds pieces until the whole system is complete. Incorporate user feedback into subsequent iterations. No more than 6 months between deployments. Minimum of 2 iterations EACH ITERATION BEGINS WITH REQUIREMENT ANALYSIS! Then, Brace for Impact!!! Resistance to change is inevitable Prepare for it. Involve end users early in the project If they don’t like it, they will not want to use it. When they feel they are making a contribution to the finished product, they will take ownership. The most expensive projects are the ones that fail because of user resistance The Project Sponsor Managerial authority over end users Has a vested interest in a successful outcome Controls the purse strings / budget Understands true project costs Unwavering support is required Must see the project through to conclusion IF THE SPONSOR BAILS, THE PROJECT FAILS! Make sure you have sufficient budget to account for project risks and contingencies Assess project risks – write them down Look at what could possibly go wrong Include funds for training and ongoing support Account for time away from regular job functions and the impact on operations The outcome will be a plan and budget that is large enough to account for risk Conclusions: Take the time to analyze requirements Diagrams speak a language that everyone can understand Take the iterative approach By implementing core functions quickly: You get feedback from end users You build momentum and support Don’t overlook impact to the organization Plan for resistance, because it will happen Understand risks and true cost to the organization  

What are your comments?

Join the discussion today. Login Here.

Comments

  • Plenty of good points, slow down to speed up, improve the requirements analysis and so on. Really nothing new but totally valid. But here we go again, UML. Sorry but no, we do not need UML for process control, and believe me I have tried, years ago. Control Engineers have had better diagrams than UML provides (for our stuff) for decades. And the software tools too. www.s88control.blogspot.com

    Reply

RSS feed for comments on this page | RSS feed for all comments