Life Cycle Approach To Managing Projects

Life Cycle Approach to
a
2001/7/18
LCAMP
Managing Projects

Using
a
Life Cycle Model to
Manage Projects
LCAMP July 18, 2001
Stephen W.A. MacLean, P. Eng.

06/12/2008
Stephen W.A. MacLean, P. Eng. 1
The views expressed in this paper are the author’s only
author’

a
2001/7/18
LCAMP
Managing Projects

Ensuring that projects meet expectations on schedule and budget is a complex challenge for
any I/T project manager.

At the CIO level, doing so for a range of simultaneous projects and enterprise-wide initiatives
can often be a major headache.

The paper will identify where current practices need improvement and demonstrate the
author’s experience in :

• Applying a Software/System Engineering life cycle model to drive project management
• Quoting, planning and delivering projects that align with corporate objectives
philosophically and practically
• Developing project criteria to link projects in a cohesive strategy
• Using project and service metrics incorporated in the model to validate the success of
projects.

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects

The CIO’s new ‘Ride’ !!

Straight from Kars by Komponents, Inc.
- your VIRTUAL car company !!!

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects

What’s Wrong with This Picture?
Time, Money or Requirements -

PICK ANY

2 ?????
?

?

? ?

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects

Patterns of Software Systems
Failure and Success
In his thorough 1996 treatise on software management practices, Jones
makes the following observation :

It is both interesting and significant that the first six out of
“
sixteen {sic}… factors associated with software disasters are
specific failures in the domain of project management, and
three of the other … deficiencies can be indirectly assigned
to poor management practices. “ 1

1 [Jones,1996] Jones, Capers : “Patterns of Software Systems Failure & Success”
(International Thomson Computer Press, Boston, MA, 1996)
06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
I would go further to say that all of the items highlighted reflect the use or lack of
use of a formal, Life Cycle Methodology and the incorporation of same into formal
Project Plans.
Approaches used on Unsuccessful Projects Approaches used on Successful Projects
1 No historical software management data Accurate Software Measurement
2 Failure to use Automated testing tools Early use of estimating tools
3 Failure to use Automated planning tools Early use of planning tools
4 Failure to monitor progress or milestones Formal progress reporting
5 Failure to use effective architecture Formal architecture planning
6 Failure to use effective development methods Formal development methods
7 Failure to use design reviews Formal design reviews
8 Failure to use code reviews Formal code reviews
9 Failure to include formal risk management Formal risk management
10 Informal, inadequate testing Formal testing methods
11 Manual design and specification Automated design and specification
12 Failure to use formal configuration control Automated configuration control
13 More than 30% creep in user requirements Less than 10% creep in user requirements
Inappropriate use of 4GL's Use of suitable languages
14
Excessive and unmeasured complexity Controlled and measured complexity
15
Little or no reuse of certified materials Significant reuse of certified materials
16
17 Failure to define database elements Formal database planning

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
There are, of course, a myriad of other factors that can result in a negative
of a project, including :
Other factors found on Unsuccessful Projects
1 Lack of user involvement
2 Lack of Executive support
3 Lack of competent staff resources
4 Excessive schedule pressure
5 Rejection of estimates by Executive
6 Destabilising corporate politics
7 Poor/untried technology choices
8 Failure to control unrealistic expectations
9 Lack of clear vision and objectives
10 Significant friction with client(s)
11 Poor team dynamics/communications
06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
Principles to be embodied in the life cycle approach :
• Architecture-first : achieve a balance between requirements and significant
design/architecture decisions.
• Incorporate iterative, RAD prototype-based approach.
• Emphasise component-based development, based upon OO technologies.
• Incorporate formal configuration control & change management practices.
• Use automated tools to support round-trip Engineering (synchronise
requirements changes, resulting in design/architecture changes and code
changes).
• Rigorous Quality Control and testing processes, with early definition of
test plans.
• Prioritise requirements and weight them if possible.
• Practice incremental delivery, based upon a formal Release management
process.
• Practice a demonstration-based review process, both for working prototypes
and incremental releases.
• Get the system working properly before trying to improve performance.

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects

Employ Capability Maturity Management
The SEI Capability Maturity Model provides a set of requirements for use in
setting up the processes used to control software product development and
software acquisition.

Optimising 5
4
Managed
3
Defined
2
Repeatable
1
Initial (Ad-hoc)

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects

SEI - CMM
Level 2

At a minimum, move from Level 1 (Ad-hoc) to Level 2
• Repeatable
• Requirements Management
• Software Project Planning
• Software Project Tracking and Oversight
• Software Subcontract Management
• Software Quality Assurance
• Software Configuration Management

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
CMM Level 2 KPA’s
Requirements Management of requirements allocated to software to resolve issues
KPA1
Management before they are incorporated into the software project

Software Project Developing estimates for the work to be performed, establishing the
KPA2
Planning necessary commitments and defining the plan to perform the work

Tracking and reviewing the software accomplishments and results
Software Project
against documented estimates, commitments and plans and
Tracking and KPA3
adjusting these plans based on the actual accomplishments and
Oversight
results
Selecting a software subcontractor, establishing commitments with
Software Subcontract
KPA4 the subcontractor and tracking and reviewing the subcontractor's
Management
performance and results

Reviewing and auditing the software products and activities to verify
Software Quality that they comply with the applicable procedures and standards and
KPA5
Assurance providing the software project and other appropriate managers with
the results of these reviews and audits
Identifying the configuration of selected software work products at
Software Configuration given points in time, systematically controlling changes to the
KPA6
Management configuration and maintaining the integrity and traceability of the
configuration throughout the software life cycle
KPA = Key Process Area, as defined by SEI

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
Rapid Configuration
Requirements Definition
Prototyping Controlled Items
& Project Plan Review
& Sign-off
Develop
Requirements REQUIREMENTS FROZEN Requirements
Project Plan
Develop
Estimating Project Plan

Develop Conceptual
Review
Conceptual Design
& Sign-off
Design

Develop
Standard
Detailed Detailed
Component DESIGN FROZEN
Design Design
Library Review
& Sign-off 1
1 of 2
06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
1 Develop First First Cut Test Configuration
Cut Test Plans Plan Review Controlled Items
Deliver to
QA Group
Develop Code
Code
Code FROZEN &
& Test
Test Plans
released to QA
Plans
Review
& Sign-off
Development
Standard Production
Integration
Test
Test & System
Review
Test
Component Release
& Sign-off
Library Develop Text
for Manuals : Training
Methodology &
Create
User Implementation
Commercial
Validation Quality
Systems Docs. Manuals Review
2 of 2 Documentation
& Sign-off
06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
% er 4th Quarter 1st Quarter 2nd Quarter 3rd Quarter 4th Quar
Project Management time embedded in each phase
Simplified Total
Status Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov
Project or Task
r r & D Project (if Required)
&DProjectIFREQUIRED)
( %VAR
%VAR

System
Development
:Version___
_ 100%
100%
System Development (Ver.: ___)
The Life Cycle
PrototypingSpecification
& 15%
Prototyping & Requirements 15% Model drives
the structure &
Design 25%
Design 40% phases of the
project plan.
Development 26%
Coding 15%
NOT the other way
Testing 26%
25%
Testing
around!
Documentation 19%
(//)
User Manuals 5%
SQA 8%
Production Release
RSC
Training & Implementation %VAR
Customer
Release 96/05/24 3:30 PM
Customer Release

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
Project Rev 1.2.0

Estimating Estimating Spreadsheet Duration
100.00% 100.00
Spreadsheet Project Management 10.50% 10.50
Ongoing project review 6.30
- uses life cycle Change Management 3.15
Management Review 1.05

metrics. Requirements Planning 12.00% 12.00
Review existing system 1.15
Model process 1.44
Identify user requirements 2.53
Prototyping (iterative) 3.28
Prepare Software Requirements Specification 3.11
Software Requirements Review(s) 0.50
Requirements Frozen 0.00
Design : Conceptual & Detailed 37.00% 37.00
Prepare Design 25.55
Document design 7.30
Prepare Software Test Plan 3.65
Design Review(s): PDR & CDR 0.50
Design Frozen 0.00
Programming 13.50% 13.50
Develop Programmes/Assemble Components 7.80
Test Programmes (complete test plan) 2.60
Document code & prepare for code review(s) 2.60
Code review(s) 0.50
Programming Complete 0.00
Development Functionality testing 9.00% 9.00
Prepare Software Test Plan 2.13
Functionality Test 6.38
Test review 0.50
Functionality Testing Complete 0.00
Development Integration Test 13.00% 13.00
Enhance test plan 3.13
Integration Test 9.38
Test review 0.50
Coverage Testing Complete 0.00
User Documentation 5.00% 5.00
Customer UAT 7.00
Conduct Software Acceptance Review 0.50

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects

Prototyping

Objective : To be able to rapidly construct a working prototype which is able to serve as a
proof of concept and high-level demonstration tool to the end-user.
Provides input to and facilitates the process of detailed requirements
definition and conceptual design.

Static : Visio (or similar) prototype consisting of : Process diagrams, with data flows
Linked screens showing data flow.

Working. : Simple screens + simple database + simplified control system.

Further steps, if required, will result from feedback from the Requirements Definition
and will result in enhanced prototypes and/or simulations.

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
Develop Conceptual Design
Objective : To establish the functional, performance, interface, design and verification
requirements.
To provide a basis for the design and development of the software.
Contents Review
Operational concepts PDR - Preliminary (Conceptual)
Operational timelines Design Review & sign off.
Operational configurations
Operational control
Major function (module) design
Approval
Sizing & timing estimates
Process/Data flow diagrams
Customer
Module interfaces
Director, Development
Method/processing sequence
Sub-contractor mgmt.
I/O definition
Major screens, reports.
Conceptual Design Document
Database design
Algorithm/methodology limitations
User interface definition Control
Standard UI functions
Class II (under control, but not released) before PDR
Class 1 (released) after PDR.

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
Business Drivers

Business Model
Strategic Inputs
• Business Principles

Architectural Principles

Organisation Information
Application
Model Model
Model
• Org Charts • Data Models
• Application
• Maturity Path Models
Portfolio
• Process Models

Technology
Model
Architecture
• Technology Stds Matrix
First!
• Refresh Model
06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
Principles for
Architecture First! &
Life Cycle Management.
• Quality must be a given.
• Drive out requirements and major design constraints early in the life cycle.
• Track requirements traceability and use metrics to measure the quality of
the architecture as the system moves from a working prototype to a full
product.
• Use automated tools to support round-trip Engineering and integrated
Configuration/Change Management.
• Use Demonstration-based evaluations to provide early insight to architectural
limitations and/or performance problems.

• Practice incremental release management - don’t compromise quality or
architecture for the sake of banging functionality into a release at the last minute.

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
Common User Interface (Browser--based)

Line of Business Applications

Document Management, Data Warehouse, Desktop, ...

Bar indicates
level of risk
to integration

ERP
strategy.

Example Strategy :
Integration

Silo 5
Silo 1 Silo 4
Silo 2 Silo3
Degree of coverage across the business
06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
• Expanding the model! Level of risk for
for a given Strategy
Degree of integration
across a Line of business
for all Strategies

Degree of integration
across the corporation
for a given Strategy

ER
P In
tegr Lin
atio e of
n Bus
ine
ss Inte
gra
tion

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
A Cohesive Strategy based upon Project Criteria
Integration Strategy Project Criteria
Required Resources

Criteria :
1. Number of
Interfaces
between
discrete
applications
2. Resources
(time, money
people, tools
…) required
to support
Number of Interfaces
interfaces.
Integration Strategy
Legacy Environment

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
Web Portal
* Vendors
* Customers E-Business
(need STRATEGY)

High-Level Architecture

ot w &
n
e

io
A evi

at
Integration Strategy

R

AD
nn

C AD
E
C
Purchasing Document
Materials Manage-
Manage- ment
ment
Human Resources

Corporate Data
FINANCE
Benefits; Time &
A/R, A/P, G/L,
Pension System Attendance, Fixed Assets
Payroll, Job Costing, etc.
Training, etc.
Scheduling
& Capacity WorkFlow
Planning
s

C pp
n es

us li
io in

A
to ca
at us

m tio
lic f B

ng
pp o

ki
A ne

ac
ce m

n
Li

an o
Tr
st
en u
nt C
ai

Data
M

Warehouse
Standardised Integration
Handheld
Hub or API Layer
Devices
EIS
Executive Information System
Sample : not a complete picture
06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
Project and service metrics
• Quality :
• Rework : % items reworked out of total items delivered
• Quality : % specifications/requirements achieved
• Delivery performance : Projects, Service Requests - % deliverables on time
• Budget performance : % Budget variance
• Customer satisfaction : # Customer Complaints by Project or System
• Process Quality : % Processes Meeting Project/Systems needs - normalised measure of
the number of Corrective Action Requests (CARS) raised.
• Uptime : % Systems and applications Available : (Available time (out of 7x24)/Total time : 7 x 24 )
• Planned Maintenance : % Systems and applications Maintained :
( Maintenance time out of 7x24)/Total time : 7 x 24 )
• Incident/Problem resolution : % calls resolved, by project or system
• Service Request Resolution : % Service Requests resolved, by project or system

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects

• Build a Solid Foundation for the future

• Deliver on-time, on-budget Solutions, that
meet Business Requirements.

Why
do it?

• Killer Processes !!!
• Powerful Tools & Technologies
• A team that has no peers!!

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
Normalised Incremental Change Cost by Stage
$ 1,000

Incremental Change Cost
Post
Roll Out

Business Testing
$ 100
Drivers.
$ 10 Coding
Design
$1
Life Cycle Stage

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects

What does your staff
get out of this?

• Reduced Stress - on and off the job!
• Increased job satisfaction
• Happier Customers
• Training and use of modern tools & technologies

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
Resulting Improvements
• Iterative, rapid prototyping, when combined with demonstration based evaluation, results in
a significant reduction in rework and costs because any significant changes are caught in the
requirements and design phases.
• Considerably improved delivery performance by quoting and managing the project in the way
the work is actually being done (the life cycle model), thus time for design, testing and
documentation is included from the start, as opposed to being an afterthought.
• Rework, as well problem/incident occurrence reduced due to avoidance of unplanned and
uncoordinated changes.
• Overall Quality considerably improved by active Scope/Change control and strict adherence to
the Architecture First principles. Fewer initial performance problems as well.

• Uptime and Customer Satisfaction improved due to improved quality and reduced rework.

06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects
In Conclusion
• While this paper has focused on software and application system process improvement,
software engineering and delivery, the principles involved are directly transferable to
infrastructure and hardware projects.
• Like any other significant process improvement effort, faith, money and management
commitment are all required in substantial doses. It is particularly important that
the organisation and the team understand the ‘J’ curve concept :
Productivity

+ Productivity Level @ Start of
- Improvement Initiative

Time
• Process Improvement is a journey - it never ends. In addition, the SEI CMM methodology,
which has only been touched on herein, provides a framework for external evaluation/audit,
but like all such frameworks, should never be taken as a ‘Holy Grail’.
06/12/2008
author’

a
2001/7/18
LCAMP
Managing Projects

THANK YOU !!!

QUESTIONS?

06/12/2008
author’

Life Cycle Approach To Managing Projects

Recommended

Recommended

More Related Content

Featured

Featured (20)

Life Cycle Approach To Managing Projects