If so try TurboProject, free for 15 days.

Click on this link for a free trial:  http://nct.digitalriver.com/fulfill/0211.048

Use this link for a video on how to use TurboProject:  www.officeworksoftware.com/demo/tp40min/TP_40min_Overview.htm

Use this link for a 50% discount: http://store.digitalriver.com/servlet/PromoServlet/promoID.5081800

TurboProject Project Planning and Scheduling Software

TurboProject™ is a feature-rich project management scheduling and tracking package. TurboProject has the ability to create project schedules and resource plans that can be used on projects as complex as launching a satellite to projects as small as organizing an office move.  Sharing information is made simple with TurboProject’s reports and Web publish feature.  Hi-quality graphics allow you to present your project with professional flair.

A couple of recommendations:

“TurboProject offers nearly all the features found in Microsoft Project at a much lower price.”

 “TurboProject earned the Smart Choice award because of its flexible interface, solid tutorial, and low price.”

Smart Computing Magazine

 “For full capabilities rivaling those of Microsoft Project, TurboProject Professional 4 is perfect for careful creation and control of projects and progress communication.”

PC World Magazine 

Contact: support@turboProject.com with any questions, or visit http://www.turboproject.com

You know it’s time to re-estimate when you hear…

1.   “That wasn’t what I wanted.”  Ensure the requirements are defined, written and agreed to by the sponsor and team. Otherwise the estimate is not worth the paper it’s printed on.

2.    “It’s different here. We have a deadline before requirements are known.”  So does your competition: Get used to it. Know and carefully manage the tradeoffs of time, staff/budget, scope, and quality.

 3.   “We can make the project go faster with more people.”  Want to go faster? Recognize the impacts of schedule compression.  The biggest timesavings come from things we don’t do; like rework. Implement practices that reduce bugs and rework. There is a minimum development time.

4.    “We estimated last year.” Recognize estimating as a continuous process.  Review at key milestones. Conduct techniques that give greater accuracy.

5.    “Of course I’m certain!”  Recognize uncertainty inherent in projects: Use probability and ranges in prediction.  Don’t schedule from a sizing.

6.  “I did it myself.”  Get a second opinion. Review the estimate with a neutral 3rd party for bias, missing tasks, unconfirmed requirements, and inaccurate assumptions. Include input of the team. 

7.  ‘Another fine mess you’ve gotten us into, Stanley!”  The surest way to make a commitment that can be kept is to know your team’s capability and make commitments according to capability.  Remember: It’s all about making a commitment you can keep that delivers required results to the business.

8.  “Never done it, but it has got to be easy.”  Allow extra time for tasks with little or no prior experience.  Avoid banking on ‘best case scenario’. 

9.  “We work an 8-hour day.”  Only lunchtime is 100% productive.  Until you can prove otherwise, use a 5-hour day for duration prediction. (60% ‘productivity’). Other urgent, important, non-project tasks will arise.

10.“Trust me.”  Question authority: How did we get this estimate? Show me your work!

11. “Relax, we’re 90% complete.” Remember the 90/90 Rule of project tracking: The first 90% of the project takes 90% of the effort; the remaining 10% takes the other 90%. Focus on effort remaining, not percent complete. Tracking is re-estimating!

 12. “Any thing printed on a color plotter has got to be true.”  Be careful not to trust tools too much; a fool with a tool is still a fool!

13. “Just say No!”  Resist the Urge!:  Do not ride in the elevator with your sponsor!

 _________________________________________________________________

About Us

Kolinger Associates has powerful solutions for better estimating and managing large projects. 

Spend your money a little differently … and get a much better result.

Also see, “7 Signs You Have a Bad Project Estimate … and What to Do About It”:  http://www.kolinger.net/2010/02/03/7-signs-you-have-a-bad-project-estimate-and-what-you-can-do-about-it/

Go to www.kolinger.net for more details.

The Software Engineering Institute (SEI) Software Development Maturity Assessment Methodology is used to assess the software development capability of organizations.  Research by Lawrence Putnam of Quantitative Software Management (QSM) demonstrates a strong relationship between Capability Maturity Model (CMM) maturity level and the QSM ‘Productivity Index’ (PI).  Specifically, rising CMM levels result in higher Productivity Indices, which result in lower development costs.

In a nutshell, higher Productivity Index values are associated with projects that cost less, finish faster, and have fewer defects.  Ideally the CMM process improvements should be associated with more efficient projects and better quality.  What’s covered in this article is that the QSM methodology, benchmark database, and tool set measure of the benefits of CMM improvements.  

This article points to the economic benefit of effective software process improvement, and the role that measurement plays in proving it.

 

Background

Many companies have undertaken software process improvement (i.e., Software Engineering Institute’s CMM/I) with the hope that better process will somehow produce better results.  For example by moving to CMMI level 3 they would expect to experience projects with shorter schedules, reduced costs, improved reliability, fewer emergencies, etc.  However, without a metrics plan and a quantitative toolset in place – apart from “anecdotal evidence” – they will never really know.   Even worse, process focus, without the right measures encourages individuals to default to rote compliance with ‘process.’ Eventually, lacking any believable measures of improvement the organization abandons the improvement effort altogether.  After all, process improvement requires discipline and continuous investment.

If you’re going to pursue software process improvement, protect the investment from the outset with a solid metrics plan and benchmark database.

Start a Basic Metrics Plan

Rather than trying to measure too much, organizations need a basic ‘starter set’ of metrics for basics such as duration, effort, size, and defects. Furthermore these metrics should not be used to measure individuals, but rather to better understand the software development process, making continuous improvement for repeatable success.  Metrics misapplied will submarine data quality and put a halt to improvement. Fear drives out learning.  Without learning there is no improvement.

Apply a Measurement Framework

Software projects are ‘different’ from other projects, such as construction.  Software does not obey the laws of physics and science.  Rather it requires human learning, discovery, problem solving and communication, which makes schedule prediction more difficult.  (When asked to estimate “how long” to complete an unfamiliar programming task the developer responds, “Don’t know.  How long does it take to catch a fish?”)

Software development projects – or most design-type problem solving projects follow a non-linear resource staffing pattern.   The sample Raleigh Curve below (Figure 2) shows the common pattern.  At the beginning of the project there is a staffing ramp-up (Physical Design), the project peaks at the conclusion of programming and the beginning of testing, and finally the long tail (Testing and Debugging) represents the effort to find and remove bugs over a considerable time frame.

Software development and circuit design projects tend to follow this effort/staffing distribution.  

[Figure 2] – The entire lifecycle of a software project follows a curve of rising and then falling manpower.  The long tail of the curve represents the many years of so-called software maintenance.

Also included in the QSM Measurement Framework are these measures:

• Effort – Person hours of work
• Duration – Elapsed days
• MBI (Manpower Buildup Index) – Rate at which people are added to the project
• Defect Density – the number of bugs to be removed
• Size – Some characterization of what is delivered. 
• Productivity Index – a macro measure of the organization’s development efficiency

Understanding the Productivity Index at a Glance

The software process Productivity Index (or PI) is a QSM metric, representing the level of an organization’s software development efficiency. The PI is a macro measure of the total development environment. PI values from 1 to 40 have been adequate to describe the full range of projects seen so far.

Low PI values typically are associated with poorer working environments, poor tools and/or high product complexity. Higher values are associated with good environments, tools and management and well-understood, straightforward projects [Ref. 1, 5].

“Productivity” encompasses many important factors in software development, including:

• Management influence
• Software development process and methods
• Software development tools, techniques and aids
• Skills and experience of development team members
• Availability of development computer(s)
• Complexity of application type

Note that the PI is calculated from the size, schedule and effort that were applied to a completed project. This means that the PI is objective, measurable and capable of being compared on a numeric scale.

Projects normalized around the PI can be meaningfully compared to one another.  Without this normalization projects’ performance cannot meaningfully be compared. For example, project A took 6 months to complete, and project B took 4 months to complete.  What conclusion can be drawn?  None.  But if both projects have PI’s then we might see that one had greater size, or greater complexity – or had a team that ramped too slowly. In any event, an organization that gets a bead on its PI has incredibly valuable information to help estimate future projects.

CMM Transition Breakpoints

Research conducted by QSM on the relationship between CMM Level and PI shows in table 3. The benchmark database consisted mostly of Level 1 and Level 2 projects (which characterize the world), therefore the relationships are statistically strongest at these levels.  In the Business Systems column we can see that average PI improves from a 12 to a 17 as the organization graduates to Level 2.

[Table 3] Transition Breakpoints for Three Application Types – Note: * Estimated

PI Improvement Reveals Economic Savings

 The graph in Table 4 shows results for three Business Systems projects of similar size and complexity.  Process improvements – which are related to PI improvements – have lead to more efficient development capability, and a much lower cost.  The transition from CMM Level 1 to 2 shows a 50% cost reduction.  The transition from Level 1 to Level 3 shows a 75% reduction in costs and a 250% improvement in reliability.

But if were to realize a 50% savings, how could it be reasonably spent?  How about these options:

• Finish faster
• Use fewer people
• Deliver more scope
• Use the saved money on other projects
• Give back to the Business

[Table 4] – The Economic Value of Software Process Improvement for Business Systems

The related graph in Figure 5 displays the Raleigh curve effort distributions for the three Business Systems projects.  Note that project duration and peak staffing decrease with CMM level improvements. This is good news.

[Figure 5] – The Economic Value of Process Improvement (Courtesy of QSM)

Is your software process improvement effort paying off?” 

Companies rightly undertake process improvement initiatives looking for some kind of improvement in delivery and cost.  To some the method of choice is the CMM, to some it’s Agile methods, to others it’s custom processes and project management offices (PMO).  But a word of caution: the project and organizational processes that can be implemented have the possibility – but not guarantee – of improving software delivery.  Organizations frequently become totally lost in process, and confuse ‘process sophistication’ with ‘real maturity’.  

Using the right measurement framework we can actually tell the difference between process improvement efforts that are paying off and those that are not.  Are we finding more bugs earlier in the lifecycle? Are the schedules becoming shorter? Is the Productivity Index increasing? Are costs dropping? Do we require fewer people to get the project completed? Is the user finding fewer bugs? Which techniques are giving us the best return on investment?  Are project estimates improving? Are fewer dates slipping?  What are the priority areas we should next focus on? The point here is that the right measurement framework helps us to know and intelligently manage the investment in process improvements to yield the best return on that investment.

You may have process improvement efforts from which you are already seeing benefit.  It’s possible that what you are seeing is only a fraction of what is possible.  Without a benchmark database you will not know the extent to which you are performing beneath your capability.

Conclusion - 

QSM’s research suggests a strong relationship between CMM level and the QSM Productivity Index.  These improvements lead to significantly reduced software development costs.  With a metrics plan and the right measurement tool set, meaningful measures position an organization to manage significant economic benefit.

Considering that the QSM tool set has a framework including industry data from over 8,000 projects, and a method to normalize project experiences, it is suitable as a software project management estimation and analysis tool.

This article points to the business case for software improvement.  If we understand the nature of CMM level 2 and 3 improvements, they are primarily focused on project management.  For this reason this article also suggests the business case for investing in project management.   

References

1. Putnam, Lawrence H. and Ware Myers, Measures for Excellence: Reliable

Software On Time Within Budget, Prentice Hall, Englewood Cliffs, NJ, 1992, pp. 32-36.

2. Humphrey, Watts, David H. Kitson and Tim C. Kasse, The State of Software Engineering Practice: A Preliminary Report, CMU/SEI-89-TR-1, ESD-TR-89-01, Software Engineering Institute, Carnegie-Mellon University, Pittsburgh, Feb. 1989, 27 p.

3. Putnam, Lawrence H., “The Economic Value of Moving up the SEI Scale”,

Managing System Development, Applied Computer Research, Inc., July 1994

4. Putnam, Lawrence H., Arlyn D. Schumaker and Paul E. Hughes, Economic

Analysis of Re-Use and Software Engineering Process, (Final Draft Report) TR-

9265/11-2, prepared for Standard Systems Center, Air Force Communication

Command, Maxwell Air Force Base, Alabama 36114, under contract FO1620-90-D-0007, February 1993.

5. Putnam, Lawrence H. and Ware Myers, Executive Briefing: Managing

Software Development, IEEE Computer Society Press, Los Alamitos, CA, 1996, 79 p. Linking the QSM Productivity Index with the SEI Maturity Level,

Version 6, 2000

 6. Putnam, Lawrence H, Linking the QSM Productivity Index with the SEI Maturity Level. July, 2000 

 7. Kolinger, Joe, Seven Signs You Have a Bad Project Estimate, Project Management Institute SF-Bay Area Chapter, January 2010

J Kolinger, February 2010

This presentation addresses the unique characteristics of software project management, with a particular focus on the people and process issues that must be managed.

This presentation was given at the PMI SF-BayArea Chapter meeting January 20th, 2010 in Walnut Creek, CA.

Download here –>  7 Signs of a bad project estimate