PM World Today Letters To The Editor
Letters to the Editor are comments on the Editorials, Viewpoints column or other project management notices that appear in issues of the Project Management World Today.
Tuesday, February 18, 2003
Past As Predictor and Earned Value - Viewpoints February-March 2003
Past As Predictor and Earned Value - Viewpoints February - March 2003
Mr. Duncan�s suggestion that EV is applicable for only large projects has not been the case in the filed of Information technology and infrastructure deployment contracting. Yes EAI 748A
(http://www.pppl.gov/ncsx/Project_Control/EIA748.pdf)
describes a profile of an EV project but this is for DCAA (Defense Contract Audit Agency)
http://www.dcaa.mil/
audit purposes and haves little to do with the effectiveness of EV as a function of the project size.
As a DOE contractor we use EV on small as well as large software development and infrastructure projects quite effectively. The size
of the project is irrelevant. The tools needed to manage are built into both MSFT Project and Primavera. There have been EV problems
in the past with MSFT Project, but 2002 has fixed those. The "analyze time series data" provides a direct mechanism for displaying
all the parameters of EV. Portfolios of projects can be evaluated as well.
In addition, the EV processes are entering the "agile" domain. Raytheon in Aurora (Denver suburb) makes use of EV with fine grained
delivers (1 to 3 days) and collects "value" thorough 0%/100% "testable requirements." This is the same process as XP's Unit Tests and Velocity calculations (minus the separation between BCWP and ACWP). We have a paper headed to the June Agile conference describing the Raytheon methods and the adaptations we've made here at the DOE. This is the process we deploy on our project.
Although Quentin Fleming makes mention of the "concept" of EV from early manufacturing, the C/SCSC process we all grew up with
in the 1980's at TRW is the basis of EAI 748B. There are not "forms and implementations" of EV. EV is defined in EAI 748B. Although the 32 criteria may not be appropriate for all project type, and there are alternate ways of computing EAC, the core metrics are fixed.
A CPI less than 1.0 alone is of little value as an indicator of slippage in the absence of scope verification, and recognition of early
delivery processes. Our agile projects many times have a CPI less than 1.0. The primary reason is the reuse of components, decreased scope not due to early delivery, improved functionality of the software to meet functional needs - all "besting" the baseline estimates made in the absence of working software early in the project. By continually engaging the customer with working code, what was thought to be a firm requirement may be reduced once the code is in hand. This is a primary feature of agile delivery - early and frequent delivery of functions for verification of requirements. A purist may object that the scope is changing - and it is: it's being reduced. With fine grained deliverables and representative CPI, the PM can rebaseline the scope without fear of confusing the observers that the scope has changed unfavorably.
Our Fixed Price + Fee, Cost Reimbursement, or Fixed Price + Incentive contracts as well as simple Level of Effort (Maintenance and
Operations), use EV as a powerful tool since all these project types can be monitored for labor contribution productivity. In addition
the Canadian Government usually requires an EVMS in a major fixed price contract to assist in support of contract progress payments.
Nick Pisano (C/S-Solutions and many EV developments) taught us a great concept. EV indicates the "return on investment measured
in units of productivity." If I invest a $1.00 of labor do I get a $1.00 of value? If I don't get a $1.00 of value (say $0.80), then simply
returning the productivity to a $1.00 for a $1.00 will not be sufficient. I must get a $1.20's worth of productivity for every $1.00 invested
to get back on track. This concept is the most powerful use of EV and works (we do it every day) on any sized project from turning a
nuclear materials contaminated building to rubble ($1B) to rolling out three ports on a switch in a trailer ($1,200). "What did I get for
my $1.00 of contribution?"
There are quite a few papers and presentations on the topic of "small" EV, ROI based EV, self directed teams using EV, and adaptable EV projects. Many of these can be found in the PMI College of Performance Management at http://www.cpm-pmi.org/
Glen B. Alleman
Director, Program Management Office
Information and Network Services
CH2M Hill (www.ch2m.com)
Rocky Flats Environmental Technology Site (www.rfets.gov)
Golden, Colorado
glen.alleman@rfets.gov+1.303.966.5865 Office
+1.303.994.0874 NexTel
Mr. Duncan�s suggestion that EV is applicable for only large projects has not been the case in the filed of Information technology and infrastructure deployment contracting. Yes EAI 748A
(http://www.pppl.gov/ncsx/Project_Control/EIA748.pdf)
describes a profile of an EV project but this is for DCAA (Defense Contract Audit Agency)
http://www.dcaa.mil/
audit purposes and haves little to do with the effectiveness of EV as a function of the project size.
As a DOE contractor we use EV on small as well as large software development and infrastructure projects quite effectively. The size
of the project is irrelevant. The tools needed to manage are built into both MSFT Project and Primavera. There have been EV problems
in the past with MSFT Project, but 2002 has fixed those. The "analyze time series data" provides a direct mechanism for displaying
all the parameters of EV. Portfolios of projects can be evaluated as well.
In addition, the EV processes are entering the "agile" domain. Raytheon in Aurora (Denver suburb) makes use of EV with fine grained
delivers (1 to 3 days) and collects "value" thorough 0%/100% "testable requirements." This is the same process as XP's Unit Tests and Velocity calculations (minus the separation between BCWP and ACWP). We have a paper headed to the June Agile conference describing the Raytheon methods and the adaptations we've made here at the DOE. This is the process we deploy on our project.
Although Quentin Fleming makes mention of the "concept" of EV from early manufacturing, the C/SCSC process we all grew up with
in the 1980's at TRW is the basis of EAI 748B. There are not "forms and implementations" of EV. EV is defined in EAI 748B. Although the 32 criteria may not be appropriate for all project type, and there are alternate ways of computing EAC, the core metrics are fixed.
A CPI less than 1.0 alone is of little value as an indicator of slippage in the absence of scope verification, and recognition of early
delivery processes. Our agile projects many times have a CPI less than 1.0. The primary reason is the reuse of components, decreased scope not due to early delivery, improved functionality of the software to meet functional needs - all "besting" the baseline estimates made in the absence of working software early in the project. By continually engaging the customer with working code, what was thought to be a firm requirement may be reduced once the code is in hand. This is a primary feature of agile delivery - early and frequent delivery of functions for verification of requirements. A purist may object that the scope is changing - and it is: it's being reduced. With fine grained deliverables and representative CPI, the PM can rebaseline the scope without fear of confusing the observers that the scope has changed unfavorably.
Our Fixed Price + Fee, Cost Reimbursement, or Fixed Price + Incentive contracts as well as simple Level of Effort (Maintenance and
Operations), use EV as a powerful tool since all these project types can be monitored for labor contribution productivity. In addition
the Canadian Government usually requires an EVMS in a major fixed price contract to assist in support of contract progress payments.
Nick Pisano (C/S-Solutions and many EV developments) taught us a great concept. EV indicates the "return on investment measured
in units of productivity." If I invest a $1.00 of labor do I get a $1.00 of value? If I don't get a $1.00 of value (say $0.80), then simply
returning the productivity to a $1.00 for a $1.00 will not be sufficient. I must get a $1.20's worth of productivity for every $1.00 invested
to get back on track. This concept is the most powerful use of EV and works (we do it every day) on any sized project from turning a
nuclear materials contaminated building to rubble ($1B) to rolling out three ports on a switch in a trailer ($1,200). "What did I get for
my $1.00 of contribution?"
There are quite a few papers and presentations on the topic of "small" EV, ROI based EV, self directed teams using EV, and adaptable EV projects. Many of these can be found in the PMI College of Performance Management at http://www.cpm-pmi.org/
Glen B. Alleman
Director, Program Management Office
Information and Network Services
CH2M Hill (www.ch2m.com)
Rocky Flats Environmental Technology Site (www.rfets.gov)
Golden, Colorado
glen.alleman@rfets.gov+1.303.966.5865 Office
+1.303.994.0874 NexTel
Thursday, February 13, 2003
"The Blame Trap" by Gillian Birkby- February 2003 PM World Today
"The Blame Trap" by Gillian Birkby - February 2003 PM World Today
This is an unpopular, yet crucial element of PM!
Over the last 20+ years of my career as an I.T. Manager, Developer, Analyst, and Project Manager, the notion that "responsibility without
accountability" seems to be the norm (at least within corporate America across the many states I've traveled.) It may be politically
incorrect to say this, but I have found that the single most common cause of project failure over the years is this "passing the buck"
mentality until alas, the "buck has stopped .." being passed because the project was terminated?
I can still remember my mum telling me when she entrusted me with something of value to her (such as her toaster oven in its state of
disrepair) that I would be accountable for its condition after "fixing" it. Maybe all we ever needed to know we really did learn in Kindergarten. We've just forgotten by the time we leave college?!
Randy Bassin
Independent Consultant
Grand Rapids
Michigan
USA
email address: rbassin@altrutech.org
This is an unpopular, yet crucial element of PM!
Over the last 20+ years of my career as an I.T. Manager, Developer, Analyst, and Project Manager, the notion that "responsibility without
accountability" seems to be the norm (at least within corporate America across the many states I've traveled.) It may be politically
incorrect to say this, but I have found that the single most common cause of project failure over the years is this "passing the buck"
mentality until alas, the "buck has stopped .." being passed because the project was terminated?
I can still remember my mum telling me when she entrusted me with something of value to her (such as her toaster oven in its state of
disrepair) that I would be accountable for its condition after "fixing" it. Maybe all we ever needed to know we really did learn in Kindergarten. We've just forgotten by the time we leave college?!
Randy Bassin
Independent Consultant
Grand Rapids
Michigan
USA
email address: rbassin@altrutech.org
Archives: September 2002 October 2002 December 2002 January 2003 February 2003 March 2003 April 2003 May 2003 June 2003 September 2003 October 2003 November 2003 December 2003 January 2004 February 2004 April 2004 July 2004 September 2004 January 2005 July 2005 August 2005 February 2006 March 2006
