JUMP: A Scalable, Successful Approach to Software Project Management<br />Presented By:<br />Michael Stefanini, Jet Propul...
2<br />JUMP – <br />Past and Present<br />
3<br />RUP<br />Toolset<br />Iterative<br />Process<br />Time-Boxed<br />
Project Strategy – The Deming Model<br />4<br />No one has to change. Survival is optional.<br />Baseline Change<br />Impr...
5<br />Artifacts<br />Checklists<br />Responsibility<br />Reviews<br />Components of JUMP<br />Authority<br />Delivery<br />
6<br />                              JUMP Roles<br /><ul><li>Each team member on the project plays a key role during the J...
There are scorecards that are individualized for each role
All role statements are defined and have clear responsibilities, authority, and deliverables for each phase
There are Affinity Groups that are formed that will provide expertise in the various areas</li></li></ul><li>             ...
DBA
Training
Change Mgmt
Communications
Help Desk</li></ul>Ops<br />Manager<br />Business<br />Product Lead<br />Customers<br />Users<br />Project<br />Manager<br...
Config Mgmt
Tech Writing
Scheduling
Dev DBA
Dev SA</li></ul>Dev Support<br />Lead<br />Stakeholders<br />System<br />Engineer<br />Resp Dev<br />Resp Line<br />Manage...
8<br />Inception Phase<br />Elaboration Phase<br />Construction Phase<br />Transition Phase<br />JUMP<br />Phases<br />
9<br />Inception Phase<br />Elaboration Phase<br />Construction Phase<br />Transition Phase<br />RFAs<br />Requests<br />f...
Inception Phase<br />Goal One: Create Excitement for Implementing this Project <br />The objectives of the project are sta...
Elaboration Phase<br />Goal One: Flesh out the details<br />An analysis is done to determine what it will take to achieve ...
Construction Phase<br />Goal One: Build it<br />The Construction Phase is a manufacturing process<br />It emphasizes manag...
Transition Phase<br />Goal One: Hand off to Operations<br />Dev Team gives product to the users and the Operations Team<br...
14<br />JUMP Reviews<br />
JUMP Review Goals and Intent<br />Goal One: Achieve Commitment and Consensus<br />The four formal JUMP Reviews are Confirm...
Scorecards are what count!<br />Scorecards & Review Materials<br />Scorecards are issued to all reviewers in order to stan...
Scorecard for Domain Architect<br />
JUMP Tools: Issues/RFA List<br />Purpose:  Monitor and Respond to Project Issues<br />Works like a Specialized To-Do List<...
19<br />Elaboration Walkthrough<br />
20<br />
Project Metrics<br />21<br />
Kick off Meeting<br />22<br />
JUMP Checklists<br />Purpose:  Show required and Optional JUMP Phase Requirements<br />This checklist not only shows the r...
Requirements in Quality Center<br />24<br />Details of the Requirements are tracked<br />
JUMP Tools: JUMP Schedule<br />Purpose:  Track major schedule and delivery milestones<br />This list serves as a simple pr...
Master Schedule<br />26<br />
Sample Mock-Ups<br />27<br />
Mock-Ups (Wire Framing)<br />28<br />
Technology Positions<br />29<br />
UX Evaluation Report<br />30<br />
Weekly Project Status Reports<br />31<br />
32<br />Measuring Success<br />
33<br />Transition<br />Schedule-Induced Delivery (De-Scoped)<br />Each Phase Builds upon the Previous<br />Construction<b...
Time Spent in Elaboration<br />34<br />NASA Study<br /><ul><li>Planning < 5% of project costs  150% - 200% Overruns
Planning > 5%, but <10% of project costs 100% - 120% Overruns
Planning > 10% of project costs  0% - 50% Overruns</li></ul>Front-End Planning includes<br />1. Defining the scope<br />2...
PMI Study<br />In the US, < 5% of total project time is spent planning with 150-200% overruns—NOT ENOUGH<br />In Japan, > ...
36<br />Inception Phase<br />Elaboration Phase<br />Construction Phase<br />Transition Phase<br />Typical Resource Use by ...
37<br />Best Practices<br />
JUMP Best Practices<br />Develop software iteratively <br />Software should be developed in small increments and short ite...
Time Boxing: Set Expectations Early!<br />39<br />Schedule(Time)<br />Scope(Quality)<br />Budget(Resources)<br />You can’t...
Customer Involvement<br />Keep customers isolated from development and testing efforts as well as internal policies<br />M...
Working with Sponsors, Stakeholder, Users, & Customers<br />Ensure your Sponsor (or delegate) is a member of the Project<b...
42<br />Development Services Catalog<br />
43<br />
44<br />JUMP TOOLS<br />
JUMP Tools: Risk List<br />Purpose:  Catalog and Track all identified project risks and mitigations.  <br />Severity is au...
JUMP Tools: To-Do List<br />Purpose:  Assign and track Action Items<br />Customize the list to meet your project needs<br ...
JUMP Tools: Estimates to Complete<br />Purpose:  Monitor budget status<br />Designed to easily provide Estimate-to-Complet...
Key Performance Indicators<br />Purpose:  Monitor and report on overall project health<br />Tracks 11 key performance indi...
JUMP Tools: Document Tracking<br />Purpose:  Track and Control Project Documentation<br />Directory Structure provided by ...
50<br />Tales from the Pit<br />
What is Your Vision?<br />51<br />
Upcoming SlideShare
Loading in...5
×

Stefanini.trinh

14,830

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
14,830
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • JUMP is a tailored version of RUP and the Iterative ProcessIterations occur within phasesJUMP is a process itself, albeit light-weight and configurableJUMP is used as a foundation on which content can be added or tailored as common sense indicatesJUMP content is managed on a JUMP siteJUMP is a Process, NOT a Procedure! JUMP provides a framework for Good Practices, but does not define a Best PracticeThe critical idea in JUMP is Iterative DevelopmentIterative Development is successively adding to and refining a system through multiple iterations, using feedback and adaptationIterations can be within a Phase, across Phases, or across the whole processIterations after completion of Elaboration should be time-boxed and kept within scopeTime and resources are fixed, while functionalities vary (opposite to traditional development)Although JUMP was originally inspired by the OpenUP and RUP processes, JUMP differs in many waysJUMP’s milestones and requirements are differentJUMP is “flavored” for JPL IT ProjectsJUMP is less complex than RUPJUMP is more of a methodology or framework while RUP contains more depth and detailsRUP concepts can be used with JUMP and the RUP Process can even be used to achieve JUMP Milestones
  • William Edwards Deming (October 14, 1900–December 20, 1993) was an Americanstatistician, college professor, author, lecturer, and consultant. Deming is widely credited with improving production in the United States during World War II, although he is perhaps best known for his work in Japan. There, from 1950 onward he taught top management how to improve design (and thus service), product quality, testing and sales (the last through global markets)[1] through various methods, including the application of statistical methods. Deming made a significant contribution to Japan&apos;s later renown for innovative high-quality products and its economic power. He is regarded as having had more impact upon Japanese manufacturing and business than any other individual not of Japanese heritage. Despite being considered something of a hero in Japan, he was only beginning to win widespread recognition in the U.S. at the time of his death.
  • Metrics reveal how many days each project remains in each phase
  • PMneeds to have a Kickoff mtg with the CM for each phase. The template is used above.
  • All Functional &amp; Non-Functional requirements are tracked in HP Quality Center. The Reviewed status will indicate if it has been approved or not. Other important metadata are also listed.
  • PM’s follow the template of the Master Schedule for their project’s deliverables.
  • Each Position was approved by the Technology Committee/Working Group and has metadata including description, status (Core), benefits, usage, etc.
  • Weekly Status Reports are created in detail from the project mgrs. Consolidated Metrics
  • Too much info
  • Combine and co-locate with customer involvement
  • Software Quality AssuranceProvide a standardized process for planning and executing tests, tracking defects, and enhancements for all projects during the software development lifecycleProject SupportCreate technical user documentation, training materials, software specifications , and online help for applicationsProject ManagementProvide consultation, technical knowledge and IT solutions to our customersFacilitate all configuration management processes and ensure development guideline complianceCustomer Support ServicesMake a commitment to provide the highest quality of service to our customers including operational help support, tool specific training, and troubleshooting user issues.Environmental Architecture ServicesProvide and design the system application hardware architecture for projects
  • CQ
  • Remember the lessons learned from the Pyramid in which each Phase builds upon the previous Phase1. Inception, the Initial Agreement2. Elaboration, there could be Scope Creep and/or Shifting Expectations3. Construction, there could be Undocumented Requirements, requiring &quot;Build and Fix&quot;4. Transition, with a Schedule-Induced Delivery (De-Scoped)...all resulting in Project Failure, from not being in position to meet the customer&apos;s needs
  • Should end with tips and traps
  • Stefanini.trinh

    1. 1. JUMP: A Scalable, Successful Approach to Software Project Management<br />Presented By:<br />Michael Stefanini, Jet Propulsion Laboratory, <br />California Institute of Technology<br />Cindy Trinh, Jet Propulsion Laboratory, <br />California Institute of Technology<br />
    2. 2. 2<br />JUMP – <br />Past and Present<br />
    3. 3. 3<br />RUP<br />Toolset<br />Iterative<br />Process<br />Time-Boxed<br />
    4. 4. Project Strategy – The Deming Model<br />4<br />No one has to change. Survival is optional.<br />Baseline Change<br />Improvement over Time<br />
    5. 5. 5<br />Artifacts<br />Checklists<br />Responsibility<br />Reviews<br />Components of JUMP<br />Authority<br />Delivery<br />
    6. 6. 6<br /> JUMP Roles<br /><ul><li>Each team member on the project plays a key role during the JUMP Process
    7. 7. There are scorecards that are individualized for each role
    8. 8. All role statements are defined and have clear responsibilities, authority, and deliverables for each phase
    9. 9. There are Affinity Groups that are formed that will provide expertise in the various areas</li></li></ul><li> JUMP Roles<br />7<br /><ul><li>SA
    10. 10. DBA
    11. 11. Training
    12. 12. Change Mgmt
    13. 13. Communications
    14. 14. Help Desk</li></ul>Ops<br />Manager<br />Business<br />Product Lead<br />Customers<br />Users<br />Project<br />Manager<br /><ul><li>QA/Tester
    15. 15. Config Mgmt
    16. 16. Tech Writing
    17. 17. Scheduling
    18. 18. Dev DBA
    19. 19. Dev SA</li></ul>Dev Support<br />Lead<br />Stakeholders<br />System<br />Engineer<br />Resp Dev<br />Resp Line<br />Manager<br />Developers<br />Dev Team<br />Standards and Process Team<br />Architect<br />Analyst<br />Technologist<br />All Phases<br />SMEs<br />Ops Team<br />Support Team<br />Core Team<br />Sponsor<br />
    20. 20. 8<br />Inception Phase<br />Elaboration Phase<br />Construction Phase<br />Transition Phase<br />JUMP<br />Phases<br />
    21. 21. 9<br />Inception Phase<br />Elaboration Phase<br />Construction Phase<br />Transition Phase<br />RFAs<br />Requests<br />for Action<br />Operational Readiness<br />Review [opt]<br />MMRs<br />Δ<br />ORR<br />Monthly<br />Management<br />Reviews<br />Conceptual Design<br />Review [opt]<br />CDR<br />IncRev<br />PDR<br />PR<br />ORR<br />IOC<br />LCO<br />LCA<br />Life-Cycle<br />Architecture Review<br />Life-Cycle<br />Objective Review<br />Initial Operational<br />Capacity<br />Project<br />Review<br />Inception<br />Review<br />Preliminary Design<br />Review<br />Operational Readiness<br />Review<br />JUMP Phases and Milestones<br />Project Vision<br />& Scope<br />Requirements<br />& Business<br />Processes<br />Observations<br />and Metrics<br />Prepare<br />Production<br />Quality Release<br />of Solution<br />Major Features<br />SRD<br />Baseline<br />New Solution<br />SRS [opt]<br />Define<br />Operational<br />Processes<br />High-Level<br />Budget<br />& Schedule<br />Evaluate Solutions<br />& Trade Study<br />Move Solution to<br />User Community<br />Risk Analysis<br />Final Project<br />Plan<br />
    22. 22. Inception Phase<br />Goal One: Create Excitement for Implementing this Project <br />The objectives of the project are stated clearly, so that the needs of every stakeholder are considered<br />Scope and boundary conditions, acceptance criteria, and some requirements are established<br />10<br />
    23. 23. Elaboration Phase<br />Goal One: Flesh out the details<br />An analysis is done to determine what it will take to achieve the vision and meet the success criteria of the Inception Phase<br />The risks, details of vision, choice of architecture, and expenditure of resources are also determined<br />11<br />
    24. 24. Construction Phase<br />Goal One: Build it<br />The Construction Phase is a manufacturing process<br />It emphasizes managing resources and controlling operations to optimize costs, schedules, and quality<br />12<br />
    25. 25. Transition Phase<br />Goal One: Hand off to Operations<br />Dev Team gives product to the users and the Operations Team<br />Involves issues of education, deployment, configuration, support, and operations<br />13<br />
    26. 26. 14<br />JUMP Reviews<br />
    27. 27. JUMP Review Goals and Intent<br />Goal One: Achieve Commitment and Consensus<br />The four formal JUMP Reviews are Confirmation and Commitment Reviews, not Design Reviews<br />JUMP Reviews will focus on the completion of JUMP Checklists and Artifacts<br />JUMP Reviews will assure commitment from responsible team members and interfaces <br />Reviews also align projects with the organization’s directives and enforce policies<br />Architecture and Technology Consolidation<br />IT Security Requirements<br />Sustainable Operations, Architecture, and Planning<br />15<br />
    28. 28. Scorecards are what count!<br />Scorecards & Review Materials<br />Scorecards are issued to all reviewers in order to standardize the review itself<br />Recommendations for Action (RFAs) will be used to capture questions, concerns, and comments and are used as a change control mechanism<br />All RFAs must be addressed promptly, can only be closed by the originator or a Board Member<br />16<br />
    29. 29. Scorecard for Domain Architect<br />
    30. 30. JUMP Tools: Issues/RFA List<br />Purpose: Monitor and Respond to Project Issues<br />Works like a Specialized To-Do List<br />Used to monitor RFAs, Customer Issues, and other problems<br />E-Mail Notification and Outlook Integration<br />18<br />Track Related Issues<br />
    31. 31. 19<br />Elaboration Walkthrough<br />
    32. 32. 20<br />
    33. 33. Project Metrics<br />21<br />
    34. 34. Kick off Meeting<br />22<br />
    35. 35. JUMP Checklists<br />Purpose: Show required and Optional JUMP Phase Requirements<br />This checklist not only shows the required JUMP tasks, but works as an assignment sheet, notebook, and status list as well.<br />Performance Indicators are generated based on the status of the items on this list<br />23<br />Monitor status and report on progress<br />Adjust the list to suit your project<br />
    36. 36. Requirements in Quality Center<br />24<br />Details of the Requirements are tracked<br />
    37. 37. JUMP Tools: JUMP Schedule<br />Purpose: Track major schedule and delivery milestones<br />This list serves as a simple project schedule. A more detailed MS Project schedule is also provided as a template.<br />The provided schedule already includes all required (and many optional) JUMP milestones – a turn-key project schedule!<br />25<br />Drag and Drop Milestones to create Schedule<br />Add, Remove, Filter, and Report on Deliveries<br />
    38. 38. Master Schedule<br />26<br />
    39. 39. Sample Mock-Ups<br />27<br />
    40. 40. Mock-Ups (Wire Framing)<br />28<br />
    41. 41. Technology Positions<br />29<br />
    42. 42. UX Evaluation Report<br />30<br />
    43. 43. Weekly Project Status Reports<br />31<br />
    44. 44. 32<br />Measuring Success<br />
    45. 45. 33<br />Transition<br />Schedule-Induced Delivery (De-Scoped)<br />Each Phase Builds upon the Previous<br />Construction<br />Construction<br />Elaboration<br />Elaboration<br />Inception<br />Undocumented Requirements<br />Scope Creep<br />Build and Fix<br />Shifting Expectations<br />Initial Agreement<br />Project Failure results from not being in position to meet the customer’s needs<br />
    46. 46. Time Spent in Elaboration<br />34<br />NASA Study<br /><ul><li>Planning < 5% of project costs  150% - 200% Overruns
    47. 47. Planning > 5%, but <10% of project costs 100% - 120% Overruns
    48. 48. Planning > 10% of project costs  0% - 50% Overruns</li></ul>Front-End Planning includes<br />1. Defining the scope<br />2. Developing the requirements<br />3. Preliminary design<br />Source: NASA study performed in 1990<br />
    49. 49. PMI Study<br />In the US, < 5% of total project time is spent planning with 150-200% overruns—NOT ENOUGH<br />In Japan, > 30% of total project time is spent planning with 0-20% overruns—TOO MUCH<br />Based on a 1995 study by C. Christensen<br />PMI suggests >20% of total project time be spent planning<br />Based on Generic Industry Studies<br />35<br />PMI suggests >20%<br />
    50. 50. 36<br />Inception Phase<br />Elaboration Phase<br />Construction Phase<br />Transition Phase<br />Typical Resource Use by Phase<br />
    51. 51. 37<br />Best Practices<br />
    52. 52. JUMP Best Practices<br />Develop software iteratively <br />Software should be developed in small increments and short iterations – a Multi-Layered Phased approach<br />Focus on risk and high value<br />Constant user feedback and engagement<br />Early cohesive core architecture<br />Detailed mock-ups of functionality<br />Take care not to confuse mock-up with product!<br />Manage requirements and scope creep<br />Change and Configuration management<br />38<br />
    53. 53. Time Boxing: Set Expectations Early!<br />39<br />Schedule(Time)<br />Scope(Quality)<br />Budget(Resources)<br />You can’t get it faster, better and cheaper!<br />
    54. 54. Customer Involvement<br />Keep customers isolated from development and testing efforts as well as internal policies<br />Minimize disruptions and avoid having the customer become a member of the development team (or Management Team!)<br />Keep the customers involved with<br />UX reviews and screen-shot updates<br />Conducting Training<br />Communications and Outreach<br />Change Control<br />40<br />
    55. 55. Working with Sponsors, Stakeholder, Users, & Customers<br />Ensure your Sponsor (or delegate) is a member of the Project<br />Recruit anyone who judges the quality of your project<br />Share the Vision often but don’t distract from your progress!<br />Gold-plating is bad businesses – Foster conservative expectations <br />Give them what they pay for<br />Build creep into your margin<br />41<br />
    56. 56. 42<br />Development Services Catalog<br />
    57. 57. 43<br />
    58. 58. 44<br />JUMP TOOLS<br />
    59. 59. JUMP Tools: Risk List<br />Purpose: Catalog and Track all identified project risks and mitigations. <br />Severity is automatically calculated<br />Performance indicators are keyed to react to the status and severity of risks<br />Un-Mitigated Red-Risks are automatically identified<br />45<br />All standard risk information is tracked in this list.<br />Status reports and views are generated<br />
    60. 60. JUMP Tools: To-Do List<br />Purpose: Assign and track Action Items<br />Customize the list to meet your project needs<br />Individual and group assignments<br />Multiple To-Do Lists can be created for several major project areas<br />E-Mail Notification and Outlook Integration<br />46<br />The list is pre-populated with tasks required to complete your JUMP Project Setup!<br />
    61. 61. JUMP Tools: Estimates to Complete<br />Purpose: Monitor budget status<br />Designed to easily provide Estimate-to-Complete (ETC) information<br />Auto-calculates variance and ETCs<br />Easily allows for budget baselines and status<br />Provides graphs<br />Track hard and soft liens<br />Performance Indicators keyed off of budget status<br />47<br />Automatically creates budget graphs on the resources pages<br />
    62. 62. Key Performance Indicators<br />Purpose: Monitor and report on overall project health<br />Tracks 11 key performance indicators (KPI)<br />8 KPIs are tracked automatically<br />48<br />KPI details for key areas are provided <br />
    63. 63. JUMP Tools: Document Tracking<br />Purpose: Track and Control Project Documentation<br />Directory Structure provided by section IM<br />Integrates with Office Applications<br />Full workflow and reporting capability<br />A separate Documents area is provided for JUMP Templates<br />E-mail documents directly to the site<br />49<br />Enable Drag-and-Drop, Alerts, and RSS feeds<br />
    64. 64. 50<br />Tales from the Pit<br />
    65. 65. What is Your Vision?<br />51<br />
    66. 66. Communicating Vision<br />Remember Goal One: Create Excitement for Implementing this Project<br />Just because you see something, does not mean you see the SAME thing<br />Communicating a vision can be difficult but must be accomplished or the project can not succeed<br />This vision is not the same as the scope or a list of features. It is the “Elevator Speech” that describes the sponsor’s BUSINESS GOALS of the entire effort.<br />52<br />
    67. 67. Scope Will Creep<br />It’s Human Nature: The more you think about a project, the more you will discover new ways to use or improve it<br />To manage scope creep<br />Include only clearly negotiated features in Inception Phase<br />Plan your resources to include Margin for these extra items<br />Ensure constant communication with your sponsor and customers<br />Manage your scope with a process that evaluates the impacts of new additions or changes<br />Manage developer’s “Gold Plating” – this is self-imposed scope creep!<br />53<br />
    68. 68. Example of ITIL Success Criteria<br />54<br />ITIL<br />
    69. 69. 55<br />Traps<br />
    70. 70. How Managers Destroy Projects<br />Usually, the Managers drive to deliver on time and on budget will be at odds with the development team’s desire to create a quality product<br />Management is well meaning and may be using proven techniques, but some have the potential for disaster<br />Here are four ways managers may unwittingly sabotage a project<br />56<br />courtesy of the TechRepublic’s Robert Bogue<br />
    71. 71. Trap #1: False Dates<br />Project managers must put dates out in front of the group to motivate them but when the dates aren’t realistic and they are consistently missed, it’s time to reevaluate the plan<br />The problem is that when a really important date comes up there will be little drive to hit it because an expectation has been set that the date isn’t important<br />After all if the team misses 10 dates in a row, how important can the 11th date be?<br />If timelines are being set that have no penalty behind them and people aren’t meeting them it’s time to put some teeth behind them or move the whole timeline<br />Developers need to be able to concentrate on their work<br />The desire to meet the date and the confusion about whether the date is real or not may lead to developers skipping critical steps in the development process and, in doing so, creating problems that will be hard to find<br />57<br />courtesy of the TechRepublic’s Robert Bogue<br />
    72. 72. Trap #1: Solution<br />Developers need to be involved in setting the schedule<br />Developers need to be held accountable when schedules are missed<br />Managers need to aggressively defend the project schedule and the developers<br />58<br />courtesy of the TechRepublic’s Robert Bogue<br />
    73. 73. Trap #2: Pretend All Is Well<br />When it comes to project management, ignorance is not bliss<br />Risks turn into a reality and then panic sets in<br />Everyone scrambles to put together the rest of the pieces of the project and the quality of the project will suffer from the hastiness of the final assembly<br />Of course, this problem isn’t fully realized until the rush that is caused when the business learns about the true state of the project after believing that nothing was wrong for a long time<br />59<br />courtesy of the TechRepublic’s Robert Bogue<br />
    74. 74. Trap #2: Pretend All Is Well<br />Solution<br />Frequent and open status reports: Try the 2-minute status report format on a daily or weekly basis<br />Utilize Project Management Office resources or your line management to report on an issue within a project.<br />You can report anonymously to the IT PMO if you need to<br />60<br />courtesy of the TechRepublic’s Robert Bogue<br />
    75. 75. Trap #3: Ignoring Dependencies<br />In software development we have a great number of techniques for delaying dependencies<br />We can stub out functions, remove connecting infrastructure, or bypass extensive error handling<br />All of these techniques when used correctly can be helpful to moving a project along<br />However, when it becomes required to get the project completed and when the costs of these techniques are not factored into the planning, trouble sets in<br />Especially when it comes to unforeseen dependencies, the clean up cost can often become a non-trivial part of the project’s overall cost—and one that isn’t discovered until the very end<br />External interfaces pose even greater risks<br />Project managers and developers often either defer discussing interface agreements or each assumes the other is working to ensure the interface will be ready<br />For unforeseen dependencies, external cooperation to provide support on the project’s time-table may be tough to get<br />61<br />courtesy of the TechRepublic’s Robert Bogue<br />
    76. 76. Trap #3:Solution<br />The solution resides with the Responsible Developer<br />The Task Plan should detail any internal and external interfaces that need to be managed<br />The developers must then communicate with the project manager if they need any political support in ensuring external interfaces are ready, but the technical aspects of the interfaces lie with the development team<br />If the Project manager ignores or defers any issues that arise, the development team must elevate the problem to another level (see Trap #2) or the project could fail<br />62<br />courtesy of the TechRepublic’s Robert Bogue<br />
    77. 77. Trap #4: Time Boxing<br />Getting top honors in the list of things which can destroy software quality is the practice of time boxing<br />Used at its extreme it often means that the code isn’t complete, it’s merely pushed along the process<br />Time boxing works—most of the time—because it does three things<br />It forces the developer to be creative in finding a solution that fits within their budget<br />It eliminates unnecessary frills and scope-creep that don’t necessarily add value<br />It ensures iteration remain smaller and manageable while deferring good ideas for later<br />The intent is to get the thing working and rely on a QA phase where detailed testing will hopefully reveal any problems that there may be with the code<br />Time boxing doesn’t always work if<br />The problem is unknown or the technology isn’t proven<br />The box is made so small there’s no possible way to complete the objective within the allotted time<br />Used for research and development, problem solving, etc.<br />When time boxing is used correctly it shouldn’t result cut corners and poorly developed software<br />It should be used with moderation to ensure the lowest cost, quickest and best quality software possible<br />63<br />courtesy of the TechRepublic’s Robert Bogue<br />
    78. 78. Trap #4: Solution<br />Time-Boxing works well when the schedule is well designed and significant margin has been allocated<br />It is the responsibility of both the Project Manager and the Responsible Developer to ensure that the schedule and Task Plan are both realistic and have sufficient margin<br />Sticking to a failed Time-Boxed schedule for the sake of meeting a dead-line is not a good idea<br />Time-Boxing is used to manage scope-creep and defend the project plan – NOT to manage the schedule or deadlines<br />Time-Boxing results in removing functionality or adding resources – not sacrificing quality<br />If the schedule runs out of margin – Re-Plan and hold a review<br />64<br />courtesy of the TechRepublic’s Robert Bogue<br />
    79. 79. 65<br />Thank You<br />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×