Industrial Software Project Management Some views on project managing industrial and business software projects

Aims of Today  Understand the constraints of managing software projects in an industrial context  Understand the key elements of software project management  Look at the advantages of using a Rapid Applications Development approach  Consider the practical aspects of running software projects

The Environment  Textbook Expectations of delivery to a predefined scope, schedule and budget Real users with a real business need for the software Constraints set by quality, safety, business operations  Reality Users not clear on their requirements Developers who will embellish the end product Expect the Unexpected

Project Truisms  80% of a delivery can be achieved with 20% of the effort.  Change in the short term is inevitable  Real development only starts after testing  See and you believe – An initial view of the software in action brings the application alive

What does successful project management look like?  Project produces quality deliverables  Everyone feels that things are ‘under control’  People clear on their role & responsibilities  Communication paths ensure key information is available  Appropriate resources are available on time  Clarity on what the delivery is  Resources are used efficiently & effectively  Project delivers on time and on budget

What is and What is not Project Management  Practical techniques to Initiate Plan Manage Deliver  Control to Ensure correct products are delivered Track against time Account for resources  Communicate to Address hot spots Build synergy  Not lots of reports and paper work  Not trying to force the impossible  Not to stymie creative thinking

Software Development Methods  Two distinct approaches Waterfall Rapid Applications Development (RAD)  Waterfall  RAD Dynamic Systems Development Method

Waterfall Technique Spec Analysis Design Build Test Key Elements Final delivery spec’d at begining Complete each phase Problems 1.Changing spec. 2.Time Slippage 3.Scope Creep

RAD Technique Prototype 1 Prototype 2 Prototype 3 Key Elements Incremental and iterative refining Component reuse Design/Build/Test cycle for each

Underlying Principles of DSDM  Active user involvement is imperative  Development teams must be empowered to make decisions  Focus on frequent delivery of projects  Deliverables driven by fitness for business purpose  Incremental and iterative development necessary to converge on an accurate business solution  All changes are reversible  Requirements base-lined at a high level  Testing integrated throughout the lifecycle  Collaborative and co-operative approach between all stakeholders

Dynamic Systems Development Method DSDM Waterfall Technique Time Resources Functionality TimeResources Fixed Varies DSDM Technique

DSDM Development Process Feasibility Biz Study Functional Model Iteration Implementation Design & Build Iteration

Comparison of Waterfall & DSDM techniques  Best for very prescriptive and low risk projects  Spec unlikely to change significantly  Full delivery is the only option  Keeps different elements of project in sync  Testing and proving starts with 1 st releases  Allows different approaches to be explored in a fast moving environment WaterfallDSDM

Design & Build Iteration  Produce prototypes engineered to a sufficiently high standard to place with user  Prototype Sequence of prototypes released to users for test Features list  Initial features  Refined initial features

Elements of DSDM  Joint Application Development (JAD) workshops Keeps developers close to the users Workshop per time box  Rapid Prototyping Development through refining a line of prototypes Prototype produced for each time box, building on previous prototypes  Time boxing Sets a development cycle Broad set of objectives created Prototype tested and evaluated at end of timebox

Timeboxing & Prioritisation  Types of Timebox Overall Timebox Lower Level Timebox End Date Fixed with aim to deliver part of the system in the box  MoSCoW Rules Must Haves are fundamental to the system defined by a minimal usable subset Should Haves important requirements with a ‘work around’ in the short term Could Haves can be left out till next increment Want to Haves can wait till later

Applicability in the Research Arena  The Project Management and RAD techniques previously described can be applied beyond the software development  The Geodise project is developing a sequence of RAD prototypes which will refine the design and aim to evolve into a practical and marketable tool for engineers  While still a research project the final outcomes will not be certain at the kick off  Aim to take a product development view that will check out the options and refine the design  New operating environment for research activities  There is a need to demonstrate alternatives to the different disciplines on the project

Project Management Processes and Components Organisation Plans Controls Stages Management Of Risk Quality Configuration Management Change Control

Project Management Organisation Project Board Project Assurance Project Support Project Manager Team Leader Team Leader Senior User Senior Supplier Executive …………..

Project Management Processes and Components Organisation Plans Controls Stages Management Of Risk Quality Configuration Management Change Control

Level of Plans Management Plan Project Plan Stage Plan Team Plan Exception Plan If necessary ‘The Plan for the Plan’

Project Management Processes and Components Organisation Plans Controls Stages Management Of Risk Quality Configuration Management Change Control

The Project Control Loop Plan Control Monitor

Techniques for Project Control  Project Reviews Check requirement not changed Confirm progress Document and action key activities Mid & End Stage Reviews Post Implementation Reviews  Project Reports Highlight Reports – Achievements, Next steps, Significant issues Exception Reports – Focus on Deviation from Plan  Re-Planning Unplanned activities will emerge Requires judgement on when to re-plan

Project Management Processes and Components Organisation Plans Controls Stages Management Of Risk Quality Configuration Management Change Control

Project Management Processes and Components Organisation Plans Controls Stages Management Of Risk Quality Configuration Management Change Control

Planning Resourcing Controlling Monitoring Risk Management Identification Estimation Evaluation Risk Analysis Risk Management

Techniques for Risk Management  Risk Assessment Identified Risk Likelihood Impact Mitigation  Risk Planning Steps to Prevent, Reduce, Transfer, Contingency, Accept Internal & External Risks  Risk Log Risks Prioritised Risks Reviewed

Project Management Processes and Components Organisation Plans Controls Stages Management Of Risk Quality Configuration Management Change Control

Quality Products Product Descriptions Quality Plan Change Log Issue Log Exception Reports

Techniques for Quality Management  Quality Plan Set of Standards to cover techniques, tools and steps in creating products  Quality Reviews Structured review of document & software Produces Issue Log Quality Log records checking carried out  Quality Planning Who, How & When Testing & Reviews will be carried out

Project Management Processes and Components Organisation Plans Controls Stages Management Of Risk Quality Configuration Management Change Control

Configuration Management  Means to control the products of the project  In Geodise Configuration Management applies to Documents (including web) Software

Product Breakdown Structure Project Component AComponent BComponent CComponent D A.2 A.1 A.3 B.2 B.1 B.3 C.2 C.1 C.3 D.2 D.1 D.3

Project Management Processes and Components Organisation Plans Controls Stages Management Of Risk Quality Configuration Management Change Control

The Balance of Change Change Risk, Cost, Time Improvement, Savings

Techniques for Change Management  Assessment of the Impact of Change Importance of Change Impact on Cost Impact on schedule Impact on other deliverables  Approval of Change Change Authority Communication of Change Approval

Conditions of Research Projects  Outcomes will not always be clear  Not all players are full time, or may be located in a range of sites  ‘Cultural’ differences between groups  Resources may be scarce  In actuality – Not any different from any other project

Keeping it simple  The techniques can be scoped according to the size of the project  Use them as a common sense check list  Simple documents are the best form of communication  Good project management is about information & communication