managing customer specific projects - aalto hughes, mike cotterell, software project ... • project...
TRANSCRIPT
Managing Customer Specific ProjectsTomas Nyström14.2.2006
”Chaos is Back”
”– 28% of IT projects succeed – 51% of IT projects are "challenged“; seriously
late, over budget and lacking expected features– 18% of IT projects are cancelled before
completion”ComputerWorld 8 November 2004.Recent statistics from the Standish Group.
The Project Defined
Scope
Schedule Budget
The Project Defined
Scope
Schedule Budget
RiskLevel
QualityTarget
Defines
Project Manager Work Profile
• What does the Project Manager Really do?– Work effort management and taking action, 85%– Resource management, 83%– Communication, 80%– Getting customer commitment, 74%– Milestone planning, 70%– Change management, 60%– Project plan management, 57%– Ensuring leadership commitment, 45%– Conflict management, 42%– Vendor management, 38%
Bob Hughes, Mike Cotterell, Software Project Management, s. 8
Project Management
Project Management
Management AdministrationLeadership
• Time reporting• Billing• Resource management• Budget tracking• Status reporting• Issue management
• Project planning
…then…
• Ensure and control the execution of the plan
• Communication• Conflict mgmt• Scope management• Risk management• “Fishing”
• Re-sell the project• Get management buy in
• Setting the direction• Aligning the people• Motivating the people• Providing an example• Giving feedback
Different Levels of Management
The Project Plan?
• Project overview: background and relation to other projects• Project contents: goals, scope, tasks, deliverables, work estimates, approaches, timetable and budget• Project structure; organization, resources, roles, teams, modes of co-operation, budget split-up, interfaces to other systems and projects• Project management mechanisms; reporting, meetings, metrics and project status tracking mechanisms, acceptance process• Project risk mapping• Assumptions that are used in the project plan
Work Breakdown Structure
• Level of detail– Project phases, activities, task packages and tasks
• Work manageability– Split work into tasks that are less than one week in
duration / effort (5 FTE)– 50 %:n compeltion is easier to identify from four 5
FTE tasks than from one 20 FTE task• Link tasks to deliverables
– One task equals one deliverable (design document, source code, test case, configuration file, ...)
– Through the deliverables the actual completion level is easier to understand
EstimationExecution effort estimation occurs in multiple places. Key is to understand what can be promised when and what the promise is founded on.
SalesSales ExecutionExecution
RFI
RFP
Req Design Build Test
Accept
Design Build Test
Prop
Deal
Entry point
Phases with estimation.
Estimation – How-toOnce the requirements are clear the actual estimation is usually not that a difficult task. The only real magic involved are the estimating factors that come out of experience. Estimation can be done top-down or bottom-up.
Top-down estimation means a high granularity breakdown based on quick requirement analysis.
Example
Bottom-up estimation means a detail breakdown based on detailed requirement analysis.
Example
Doing this usually requires customer interaction as a result of increased understanding of the solution. Never estimate anything you have no previous experience from!
Estimation and Deal Type (Simplified)
Deal type plays a key role in sales process. Fixed price is usually more heavier as it indicates cost control while time & material indicates value thinking and thus emphasis of overall business case.
SalesSales ExecutionExecutionRFI
RFP
Req Design Build Test
Accept
Design Build Test
Prop
Deal
Entry point
SalesSales ExecutionExecutionRFI
RFP
Req Design Build Test
Accept
Design Build Test
Prop
Deal
Entry point
Fixed Price. Price or effort needs to be committed in advance. All time above agreed price usually at own cost.
Time & Material. Price or effort needs to be committed in advance. All time above agreed price usually at own cost.
Requirements Definition. If requirements are unclear and a fixed-price or a better fork is wanted a short requirements definition phase is usually called for,
(Sales)(Sales)SalesSales ReqReqRFI
RFP
Req
Prop
Deal
Entry point
Prop
Deal
ExecutionExecution
AcceptDesign Build Test
“Process Model”The methodology is extremely important and is usually one of the competitive advantages. The process model is part of the methodology and has a varying role from project to project. Sometimes the client enforces it - sometimes it is left open.
”Delivery Methods” Library
AccentureDelivery Processes
AccentureDelivery Tools
AccentureDelivery Architectures
Accenture Delivery Metrics
AccentureDelivery Methods
Deep inside
Definition - Quality
Q: What’s the definition of Quality?
A: Zero DefectsB: Degree of ExcellenceC: Conformance to Customer RequirementsD: Doing It Right The First Time
RequirementsRequirements are key to understanding effort. Requirements are extremely difficult to comprehensively document (ambiguity & completeness & internal consistency). Requirements can be categorized into two groups; functional and non-functional.
Functional Requirements document the functionality of the system. Typically functional requirements contain the following type of documents:
• Use Cases• Business rules• Screen shots• High level domain model• Interfaces• Batch runs• Reports• …
Non-functional Requirements document everything else. Typically non-functional requirements cover areas that the end-user or interface does not care about from a functional point of view:
• Technology (J2EE / .NET / C++, Application Server, DB, OS, middleware, …)• Use of existing frameworks (Company internal, 3rd party or open-source)• Performance (response times, memory consumption, CPU usage, scalability, frequencies etc)• Integration technology (real-time, batch, …)• Localisation (Languages, currencies, time-zones, calendars etc)• End-user requirements (PC requirements, browser requirements, mobility devices) • Security (authentication, authorization, auditing, …)• Administration• Operational requirements (backups, system administration, user mgmt etc)• Tools (IDE, requirements mgmt, issue tracking etc)• …
Without proper requirements estimation can only at best be benchmarking.
AssumptionsOnce the estimation is done a number of assumptions have (hopefully) been identified. These assumptions are critical to document as part of the proposal to ensure no holes exists.
Assumptions = Your understanding of the requirements
Assumptions = Scope clarifications / scope demarcation
Examples of detail assumptions on functionality:• Missing Use Cases (logical gaps)• Unclear Use Cases (missing steps, screens, interface definitions etc).• …
Example of detail assumptions on non-functionality:• Interface technologies• Performance• …
Example of detail assumptions on responsibility demarcation:• Conversions• Interface technology• Hardware• Software licenses• Training• End-user documentation• Client performed work / client responsibility• …
Is the Customer Always Right?
Yes and No
The customer has the right to decide but is not always right.
Leading Customer People
If you have a number of customer people participating in the execution phase responsible for parts of delivery you have both an upside and challenge.
Communication LinesUpsides:• Buy-in• Knowledge transfer in• Knowledge transfer out• Teaming with the client• …
Potential challenges:• Scope creep• Performance problems• How to be tough and get things
done?• ..
Usually the more client people are involved in the execution phase the higher the likely hood of success –assuming not too much delivery responsibility is burdened on the client.
Client management
Client project manager
Client team lead
Client developers
Reporting and Transparency
Reporting is a standard part of any project / program. Reporting should be used to build client relationship. Reporting is also one way to ensure transparency – key to a trusted relationship.
WeeklyProjectStatusReport
MonthlySteering
Committee
WeeklyTeamLead
Reports
Available to the client
Project internal
reporting
Scope
Schedule Budget
Level of visibility?
Reporting should focus around:
Steering CommitteeSteering committees exist to support project management. In SC the project management gets approval for key decisions and in certain situations the SC will independently of project management dictate next steps and direction.
Use the steering committee to:• Ensure continued buy-in / re-sell the project• Get face time with senior client people• Get support in key decision• Ask resolution in issues• Go through key risks and the mitigation plans
Remember to:• Keep it simple – key senior client people might
have quite a few project to sit through each week• Remind of the goals of the project• Take notes and maintain an action list• Have a balanced view – do not be too optimistic or
pessimistic
Issue #1:…
1. Situation2. Complication3. Solution
• Summary• Budget• Overview (graphical)• Overview (text)• Issues• Risks
WeeklyProjectStatusReport(Word)
MonthlySteering
Committee
(PowerPoint)
Project / Program Manager view of the situation (focus on risks and issues)
Highly condensed
(1-2 slides) (3-5 slides)
Scope ManagementDuring the project a rigorous issue / defect / change request management process is required. All projects will generate scope creep unless managed well. A tool and well defined process to manage scope is needed to remove any “feelings” from the client communication.
Issues
Defects
Change Requests
Approved
Rejected
Postponed
Tool&
Process
Scope
Schedule Budget
Impact analysis
Changes
Use project estimation tool to estimate changes in scope
What is a Successful Project?
• Customer success (quality)– Expected deliverables– Time / budget
• Internal success– People development– Time / budget– Project margin– The customer recommends you
