After one particularly difficult midterm in college, my professor said, "This is just a wakeup call; there's still time to improve before the final." I think that wakeup call was particularly painful, but my professor's words stick with me today, especially when thinking about data collection (or lack thereof) when a project is over.

As someone who is not a project manager, it was difficult for me to understand why project managers would not collect their own historical data. I understand now that after a project is finished, people move on to the next project and there's no time to update project stats. Recently, I read a post on Gantthead.com by Kenneth Darter called, Project Closure: Party or Post-Mortem?. Darter says if the project was a success, then it's important to record why it was successful; if the project was not successful, it's important to capture why it was not successful.

The word "data" in Latin literally means "things having been given." At the end of a project, you have been given a lot of things that only you and your team know: size, effort, duration, staffing, PI, cost, etc. If you are able to take a moment to fully document your project information, you not only build a historical database, but you're able to reflect back on that project to improve future endeavors (whether you would like to remember it or forget it completely). Darter recommends creating a checklist which, "should be defined early on in the project and communicated to everyone who will have input into the checklist at the end of the project." In addition to project specific information, he specifically recommends these three items:

Our recent webinar, Estimating Before Requirements with Function Points and Other Metrics, was a huge success! If you were unable to attend, a replay and pdf version of the slides are now available. If you have any questions regarding this material or QSM's Function Point Analysis services, please do not hesitate to contact us.

It is well known that project estimating based on parametric models has reached a sophistication where realistic estimates, schedules and predictable outcomes are indeed possible given a set of software and systems requirements. However, increasingly with the fast pace of Agile and other development methods is the requirement for estimates much earlier in the life cycle. What happens when project estimating moves back a full phase – before requirements, and acquisition managers, contractors, auditors and financial analysts are forced to develop and analyze estimates based on unknown requirements? Presented by industry expert Carol Dekkers, this presentation examines how to identify and document assumptions, create a logical and traceable project map including locations of potential “landmines” (calculated risks) that accompany this preliminary estimating. Experienced estimating professionals and contract managers will find a basis for common ground in this presentation – as the advice presented will create the basis for dialog and discussion of early estimates.

Watch the full replay here!

On Thursday, June 7 at 1:00 PM EDT, QSM will host Estimating Before Requirements with Function Points and other Metrics, presented by industry expert Carol Dekkers.

It is well known that project estimating based on parametric models has reached a sophistication where realistic estimates, schedules and predictable outcomes are indeed possible given a set of software and systems requirements.  However, increasingly with the fast pace of Agile and other development methods is the requirement for estimates much earlier in the life cycle. What happens when project estimating moves back a full phase – before requirements, and acquisition managers, contractors, auditors and financial analysts are forced to develop and analyze estimates based on unknown requirements?  Presented by industry expert Carol Dekkers, this presentation examines how to identify and document assumptions, create a logical and traceable project map including locations of potential “landmines” (calculated risks) that accompany this preliminary estimating.  Experienced estimating professionals and contract managers will find a basis for common ground in this presentation – as the advice presented will create the basis for dialog and discussion of early estimates.

QSM is pleased to announce that we are now an approved PMI Registered Education Provider (R.E.P.), making it easier than ever for SLIM Training attendees to earn PDUs! R.E.P.s are organizations that have been approved by PMI to help project managers achieve and maintain the Project Management Professional (PMP)^®, Program Management Professional (PgMP)^® and other PMI professional credentials.

QSM's SLIM Training Course teaches attendees how to accurately estimate project size (scope) and calculate productivity to project risk-buffered effort-time trade-offs. Additionally, attendees learn how to leverage the SLIM tools for tracking, variance, analysis, forecasting, and benchmarking to manage risk as a project unfolds, as well as analyze key project metrics to meet project business goals and plan continuous software process improvement efforts.

The full SLIM training course is 19 PDUs. Students taking the full course can claim 6 PDUs for PMI Risk Management Professional (PMI-RMP)^® and 4 PDUs for PMI Agile Certified Practitioner (PMI-ACP)^SM.

Read the full press release.

PMP, PMI-ACP, PMI-RMP, and PgMP are registered marks of Project Management Institute, Inc.

Please welcome Carol Dekkers who joins QSM as a part-time Consultant and Trainer. Carol will be a member of our consulting team and also assisting as needed with our research and training needs. Carol has been a longtime teaming partner of QSM and those of us who have worked with her know that she is an excellent speaker, writer, trainer and consultant.  

Carol is a recognized international expert in the software metrics and IT Project Management industries. A former President of the International Function Point Users Group (IFPUG), Carol has been project editor of the U.S. delegation to ISO software and systems engineering standards in function points and benchmarking (ISO/IEC JTC1 SC7) since 1994. 

I am often asked this question during SLIM Training classes.  I remember wondering about that myself.  It is a logical question since SLIM-Estimate workbooks are often imported into SLIM-Control to create the baseline project plan.  The answer is ‐‐ they are not directly related, because uncertainty ranges, probability curves, and control bounds are designed to perform different tasks.  This post is the first in a series looking at risk associated with an estimate, risk of your project plan, and handling deviations from the plan.

What are we talking about?

The first thing we need to do is define some very important terms that are often misused (I am the first to admit I have been guilty!).  I went to good old Dictionary.com and looked up the following:

QSM is pleased to welcome Andy Berner to our development team as a Senior Software Engineer. He will be supporting the product development team on new SLIM software estimation, forecasting, and benchmarking products as well as the IBM Rational integrations. As an IBM Rational Partner, QSM has had the privilege of working with Andy over the last several years designing and implementing integrations between the SLIM Tool Suite and the IBM Rational applications Rational Team Concert, Rational Focal Point, and Rational Method Composer.  

Andy Berner joins our team with experience in a wide variety of areas in software development. Andy came from IBM where he was lead architect for enablement and strategy in the Ready for IBM Rational program. Andy has done extensive consulting on software development methods and tools, recently focusing on integrations of tools and team members throughout the software lifecycle. Prior to IBM, Andy spent 11 years at EDS. In a former life, Andy was a research mathematician and teacher, and is now looking forward to helping QSM customers improve their ability to manage and control their projects.

A few weeks ago, Thomas C. Redman posted Demand the (Right) Right Data on the Harvard Business Review blog, about how managers should set the bar higher, in terms of data.

Why are managers so tolerant of poor quality data? One important reason, it seems to me, is that most managers simply don't know that they can expect better!  They've dealt with bad data their entire careers and come to accept that checking and rechecking the "facts," fixing errors, and accommodating the uncertainties that using data one doesn't fully trust are the manager's lot in life.

Although Redman suggests that managers should demand higher quality data, I immediately thought about how to check the quality of SLIM-DataManager databases using the Validate function and SLIM-Metrics.

If you're using SLIM-DataManager to create your own historical database, you can use the Validation feature to help you demand the (right) right data.  The Validation feature in SLIM-DataManager analyzes the projects in your database, highlights suspect projects, and offers a brief explanation tool tip.  Simply go to File|Maintenance|Validate to run this feature and wait for SLIM-DataManager to analyze your database.  If SLIM-DataManager detects anomalies, it will highlight that project in blue.  If you hover over that project, a tooltip will explain what is wrong with that project data and what you need to take a second look at.

A colleague of mine recently sent me a blog post explaining the difference between project contingency and padding.  The blogger made the distinction that padding is what often gets added to an individual’s estimate of the effort required to perform a task (in her example, a software development task) to account for project ‘unknowns’.  The estimator determines the most likely required effort, then pads it with a little more effort in order to arrive at an estimate to which he or she can commit.  Thus, padding represents an undisclosed effort reserve (and implied schedule reserve) to buffer against potential risk.  Contingency reserve, she explains, is “an amount of money in the budget or time in the schedule seen and approved by management.  It is documented.  It is measured and therefore managed.”  Ms. Brockmeier is correct in promoting contingency as the better management tool.  The challenge is having a method to measure and document this contingency and the known unknowns it is buffering.

Implicit Risk Buffer

Padding is a natural result of bottoms-up, effort-based estimation techniques.  Estimating low-level WBS elements creates more opportunity for padding, because the number of unknowns grows with the task list.  The estimator is consciously or unconsciously assessing the risk of each task, considering its dependencies and complexities.  What is being implied in the effort estimate is: 1] an assessment of product size and complexity, and 2] a productivity valuation.

If you were unable to attend our most recent webinar, Successful Estimating Processes Using the SLIM API, a replay is now available.

How do best in class development organizations achieve maximum return on investment from their estimation programs? By leveraging the SLIM API for integrations between estimation tools and detail-oriented products, development teams are able to simplify estimation processes and broaden the estimation program user base. Presented by Carl Engel of IBM Global Services, Scott Lancaster of State Street, and Larry Putnam, Jr. of QSM, this webinar explores two successful implementations of the SLIM API between third party tools and the SLIM Suite. 

Carl Engel is the Estimating Program Manager for IBM's Global Business Services responsible for the development and deployment of performance benchmarking and estimating process, methods and tools including the support for nearly 1,000 SLIM Suite users. Carl has been with IBM for 12 years as an Associate Partner and has had previous roles as the program manager for IBM's project management methodology and tools. He is an IBM certified Executive Project Manager, PMP with over 30 years of program and project management experience primarily in very large scale efforts in the nuclear industry and U.S. National Laboratories.