Rethinking the development process
0 likes719 views
The document discusses IT governance and rethinking development processes, emphasizing the need for innovation in services through various strategies. It introduces principles of elastic and embedded governance, which encourage adherence to procedures while supporting innovators. The document outlines governance stages and stages in project management, including planning, implementation, and review.
Rethinking the development process
- 1. IT Governance RETHINKING THE DEVELOPMENT PROCESS
- 3. Development “the change needed to improve a service by innovating*” Idea! Problem! Realised Benef Innovation Improvement *innovation = the use of a new idea or method.
- 4. Development in the Large: Solutions and Services not (just) Software • technology demonstration, advocacy and training • improving processes, procedures and standards • bulk data transformation • automating a regular task • configuring a system • coding or installing software • experimenting with technology capabilities
- 5. Influencers: Methodology Theory and Practice
- 7. Principle: Elastic Governance. A single model; shared standards; multiple patterns. Adapt the model to fit the work. Plan and measure work at the highest level possible to complete the right work to the required level of quality.
- 8. Principle: Embedded Governance Governance is about guidance not control. Make it harder to avoid procedures, guidelines and standards than it is to use them. Encourage innovators without compromising service reliability or user experience. Coach and advise.
- 9. Benefits What did we Business Case gain/learn? Is it desirable? 5 1 Propose 0 Plan Review Backlog of Solution Design 2 Ideas and Is it feasible? Issues Release Plan Service Operation Is it ready? 4 Implement 3 Service Delivery Is it viable?
- 10. Common / Key End RHUL Project Governance Stages Simple Project Simple SDLC Deliverables Milestones Framework Start Up Project Proposal M1 Gateway 0 Propose Justification Detailed Business Case M2 Gateway 1 Initiation PID M3 Requirements Requirements Definition Requirements BlueprintM4 Architecture & Feasibility Architecture Model M5 Plan Gateway 2 Detailed Design Design Blueprint M6 Design Gateway 3 Buy/Build Development Plan M7 Build Testing Test Plan; Detailed Test M8 Plan; Test Results Implement Integration Integration Plan; M9 Accept Reference Architecture Installation & Verification Installation Plan and M10 Deployment Package; User Documentation Deploy Transition Planning & Validation Release Plan; Service M11 Gateway 4 Model Release Operation Service Operation Form M12 and Support Package Maintenance Change Request M13 Process Transition Review Lessons Learned M14 Gateway 5 Review Closure Project Closure Report M15
- 11. Rethinking the Development Process Information Technology This slide deck is licensed under a Creative Commons Royal Holloway, University of London Attribution-NonCommercial-ShareAlike 3.0 Unported October 2012 License Author: Alison Pope, alison.pope@rhul.ac.uk Contributors: Alison Pope Version: 1 Revision: 4
- 12. References • Geek and Poke http://geekandpoke.typepad.com/geekandpoke/2012/01/simply- explained-dp.html • Coding the Architecture by Simon Brown: http://www.codingthearchitecture.com/pages/book/just-enough- architecture.html • Definitions of Design Thinking by Tim Brown (http://designthinking.ideo.com/?p=49) • Design Thinking by Tim Brown (http://hbr.org/2008/06/design-thinking/ar/1) • Design ... Design Thinking by Nitjyot Saroan (http://blog.emerson.edu/integrated_marketing_communication/2009/10/design- design-thinking.html) • Project Enterprise Architecture Toolkit (PEAT) Navigator: Essentials and Key Concepts Module http://www.exeter.ac.uk/value/casestudies/enterprisearchitecture/resources/
Editor's Notes
- #2: AP
- #3: The Horrible Reality?
- #4: What is development work?
- #5: What is development work?
- #6: REFERENCE TEXTCoding the Architecture by Simon Brown: http://www.codingthearchitecture.com/pages/book/just-enough-architecture.html“At one end of the scale you have waterfall that, in it's typical form, suggests big design up front. And at the other end you have the agile methods that, on the face of it, shy away from doing architecture. At this point it's worth saying that this isn't actually true. Agile doesn't say "don't do architecture", just as it doesn't say "don't produce any documentation". Agile is about sufficiency, moving fast, embracing change and delivering value. But since agile methods and proponents don't put much emphasis on the architectural aspects of agile projects, many people have misinterpreted this to mean "agile says don't do any architecture".Sitting between the ends of the scale is the Rational Unified Process (RUP). Many RUP implementations are heavyweight monsters that have more in common with waterfall than they do with other iterative and incremental methods, but RUP can be scaled down to exhibit characteristics that let it take the centre ground on the scale. At its heart, RUP is a risk-driven methodology that basically says, "gather the majority of the key requirements, get the risky stuff out of the way, then iterate and increment". Done right, RUP projects can have a nice balance of up front design and evolutionary architecture.”
- #7: REFERENCE TEXTDefinitions of Design Thinking by Tim Brown (http://designthinking.ideo.com/?p=49)Design Thinking by Tim Brown (http://hbr.org/2008/06/design-thinking/ar/1)Design ... Design Thinking by NitjyotSaroan (http://blog.emerson.edu/integrated_marketing_communication/2009/10/design-design-thinking.html)“Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”
- #8: How to we adapt and scale the RHUL Project Governance Framework so it is suitable for all kinds of IT development work (projects, application and annual lifecycle maintenance, work requests and product management)?
- #9: How to we make governance processes simple, easy to understand and easy to use?
- #10: SIMPLE ADAPTIVE DEVELOPMENT PROCESS and GOVERNANCEUsing simple project stages and ‘design thinking gateways’.
- #11: PROJECT STAGES and DELIVERABLESReferencesAdapted from Project Enterprise Architecture Toolkit (PEAT) Navigator: Essentials and Key Concepts Modulehttp://www.exeter.ac.uk/value/casestudies/enterprisearchitecture/resources/
- #12: AP