I have been a software project estimator for 20 years.  Like many people who have worked a long time in their profession, I find myself applying my work experience to other events in my life.  So, when a family member tells me that he or she will be back from a trip into town at 3:30, I look at their past performance (project history) and what they propose to do (project plan) and add an hour.  Usually, I am closer to the mark than they are.

Focused on planning for software projects, this IEEE presentation by Keith Ciocco explains some of the key components of a successful estimation process. This is a summary level view focusing on the importance of leveraging historical data, sizing, and measuring productivity when estimating at the organizational and project level. This presentation includes a demonstration of the SLIM Suite of tools to show how we can automate and streamline the estimation process.

Watch the replay of this presentation!

QSM is pleased to announce the availability of SLIM Suite 9.0. The new release provides users with enhanced data collection features to more accurately plan software development projects based on industry statistics and trends.

This updated version of QSM’s cornerstone product improves integration between the desktop and the web and streamlines data entry, historical data collection, and analysis to increase data quality and accuracy throughout the software development lifecycle.

In addition to integration and data entry improvements, other new features introduced with today’s release include:

When it comes to agile, there are common myths and misconceptions about project estimation and tracking. In Part 2 of this PDU-approved two-part webinar series (which can be viewed independently or together), presented by QSM's Andy Berner offers corrections to these, such as:

• Why velocity is not a good predictor of release duration
• Why burndown charts will not be close to straight lines
• Why change and churn are not the same thing
• Why looking at just the values of metrics alone is not enough

While some longstanding principles about software estimation still apply, agile methods require some significant changes to how we estimate. This webinar shows you how to leverage the SLIM estimation and tracking tools to properly interpret metrics collected by agile teams and ensure that agile projects meet their goals. Andy Berner demonstrates how SLIM fits with the principles of agile development, and discusses milestones, productivity, project control, data collection, and looks with an eye towards further research.

Watch the replay!

QSM is pleased to introduce our Estimating and Tracking Agile Projects workshop, the latest in our popular workshop series.  We introduced a number of workshop offerings last year in response to a growing demand for basic educational courses on software estimation and project management from our clients and prospects. 

The purpose of our Estimation and Tracking Agile Projects workshop is to give students a clear understanding of how to estimate and track agile projects at the project release and portfolio level which, in turn, helps establish more reasonable expectations for developer sprint/iteration level planning. Participants will learn how to "embrace change" in the estimation and tracking process while also effectively managing stakeholder expectations based on scope. The workshop content includes the most effective methods for sizing agile projects and uses SLIM as an example to show how a scope based parametric tool can be used to estimate and track effort/cost, duration and quality in an agile environment.

After completing the workshop, attendees will have the ability to estimate and track agile projects at various stages in the software development life cycle. They will also be able to explain, from a software estimation perspective, what makes software projects using agile methods truly unique vs. differences in terminology.

QSM offers a number of additional agile resources for our clients and prospects, including articles, blog posts, and our upcoming Agile Estimation: Beyond the Myths, Part 2 webinar.

We are pleased to announce that QSM has been included in the list of 2015 "Cool Vendors" in the IT Vendor Management category by Gartner, Inc.

Each year, Gartner identifies a collection of companies in key technology areas and publishes a series of research reports that objectively highlight these companies from a customer perspective. The reports are meant to be succinct, filter through hype, hone in on vetted and proven innovations, and identify those vendors that are creating unique value in their market space. Many of the organizations that Gartner profiles are transforming the way businesses and government agencies leverage technology in innovative and useful ways. As the universe of outsourcing and third-party IT services continues to expand, Gartner singled out three front-runners in the burgeoning field of strategic vendor management.

 “It is very gratifying to be recognized by Gartner,” says Joseph A. Madden, QSM’s Vice President of Professional Services. “The 2015 Cool Vendors in Vendor Management is an independent and well-researched piece, and we consider inclusion to be testament to our thought leadership and almost 40 years of contributions to the discipline of using project metrics to make smarter IT investments.” Madden added, “the unique QSM edge is to harness historical project information and quantitative measurement to remove a lot of the politics, emotion and bias from vendor relationships: the data seldom lies and has no agenda.”

Too many projects are late, over-budget, under-delivered, or a combination.  The problems continue despite widespread awareness and improvements in project management knowledge, tools, and process maturity.  

A recent piece in the Washington Post business section identified a likely culprit: “the planning fallacy”.  Princeton psychologist Daniel Kahneman and Amos Tversky of Stanford describe it as “the tendency to underestimate the time, costs, and risks of future actions and overestimate the benefit of those actions”.  The results are time and cost overruns as well as benefit shortfalls.  The concept is not new: the pair coined the term in the 1970s and has been researching it since.

According to the Post, cognitive biases such as optimism bias (the tendency to expect positive outcomes from one’s actions) and overconfidence can be causes of the planning fallacy. There is a growing body of evidence, collected by researcher Bent Flyvbjerg at Oxford University, that optimism bias is an important bias affecting the quality of forecasts in project planning. 

Other explanations of the fallacy include possible intentional and deliberate considerations on behalf of the planner - such as incentives, organizational pressures and strategic deception. 

Our recent webinar, Agile Estimation: Beyond the Myths, Part 1, presented by Andy Berner, featured a lively Q&A session. Here are a few of the highlights that you can catch in the PDU-approved replay.

Q: You talked about different types of work and how they're done concurrently. What about the work of developing the system architecture?

A: How architecture is determined in agile projects is a really interesting question. Grady Booch, who is one of the great proponents of software architecture used to say that the biggest difference of opinion between him and Kent Beck, who is thought of as the inventor of agile, was the extent to which architecture is planned versus evolved. So there's controversy, but I think all agile methodologists would agree that some basic architecture constraints are an input to the coding work, and thus we would consider that as part of "getting to ready," and also agree that some detailed architecture decisions evolve along with the detailed design as part of “getting to done.” So it's split.  The more complex the project, the more likely you’ll need strong architectural input that was part of "getting to ready" and should plan more architectural effort as part of the "getting to ready" portion.

Q: Can you create an agile estimate using function points as an input?