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
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/
Notas del editor
AP
The Horrible Reality?
What is development work?
What is development work?
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.”
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.”
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)?
How to we make governance processes simple, easy to understand and easy to use?
SIMPLE ADAPTIVE DEVELOPMENT PROCESS and GOVERNANCEUsing simple project stages and ‘design thinking gateways’.
PROJECT STAGES and DELIVERABLESReferencesAdapted from Project Enterprise Architecture Toolkit (PEAT) Navigator: Essentials and Key Concepts Modulehttp://www.exeter.ac.uk/value/casestudies/enterprisearchitecture/resources/