QSM is pleased to welcome Taylor Putnam to the QSM Research and Technical Support team. Taylor joins QSM with a strong research background. Throughout college and her time interning for QSM, she has conducted studies on risk perception, complex decision making, behavioral economics, and project sizing. Taylor graduated cum laude from Dickinson College with a B.A. in Psychology and a minor in Spanish.

Taylor will be assisting in peer reviews for product documentation, new product testing, research to support consulting engagements, validating new projects for the QSM Database.

SLIM-WebServices is here! We are pleased to introduce the newest generation of SLIM tools: a "light and lean," cloud-based version of our world-class project estimating, tracking, and benchmarking products. With a streamlined structure and simplified user interface, SLIM-WebServices endows more people in more positions at more places in an enterprise with sophisticated project estimation intelligence – improving visibility, transparency, and global collaboration.

Whether you’re conducting a feasibility assessment, estimating a new project, tracking ongoing projects, building a historical database, or benchmarking your completed projects, SLIM-WebServices support better decision making at each stage of the software lifecycle. This powerful, yet easy-to-use tool delivers fast results using minimal inputs, allowing estimators, project managers, stakeholders, and senior management to quickly and easily share information and lessons learned. SLIM-WebServices mirror the software development lifecycle, and encourage the adoption of enterprise-wide standards for project estimation, tracking, and benchmarking.

Read the full news release.

At QSM we offer Estimation Process Consulting Services and the SLIM-Estimate tool. In my 16 years at QSM, I have probably spoken with hundreds of project managers about the pain that they have in the estimation area. Many tell me that they want to finish implementing their process before they bring in a tool.

One of the things that I have learned over the years is that it can be extremely beneficial to bring in the tool while the process is being developed. A successful estimation process implementation is about getting the right project data in the right place for consistent collaboration and results. Implement both the process and the tool at the same time and you can save a ton of money in rework costs down the road. 

A good estimation tool provides a roadmap and a communication vehicle for a successful estimation process. The tool collects the core metrics that the process requires. It also streamlines the results to give the user exactly what they need to know: risk, size, duration, effort, reliability, and productivity.

Some will spend years writing and implementing their process. Why not get the estimation tool in place sooner to make things easier?

Imagine we are starting a new Agile project, one that is key to our competitive position. We need to deliver in six months. Our competition is already in the market, so we must at least match them on features and quality. This project is twice as large as other projects we've done recently, but the project is important enough to put our best people on it. Two teams stand out - their velocity is consistently high on the projects they've completed. If we put those teams together, their combined velocity should do the trick! Well, maybe it's not quite that easy. In Predictable Change - Flexing the Five Core Levers of Software Development, Dr. Andy Berner from QSM introduces the key metrics used to predict what it takes to do a new project and some of the issues you'll encounter when moving from Agile iteration planning to planning new projects and releases. 

Dr. Andy Berner is a senior software engineer at Quantitative Software Management, Inc. Previously, Andy worked at 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. He now helps QSM customers improve their ability to manage and control their projects. 

Download the free white paper now!

The 2012 Olympics are over and it will be another four years until we can all discuss how much we hate NBC's coverage.   Susy Jackson of the Harvard Business Review blog points out in her blog post  that while the games of years past have been huge spectacles  of debt, the London Olympics have attempted to be "green," in that many of the structures built for the 2012 games will be reused for the 2016 Rio games and other events.  Instead of building permanent structures that will be abandoned shortly after the games are over (HBR mentions the " temporary arenas still standing in tatters in Beijing, frogs inhabiting an abandoned training pool in Athens, a forgotten ski jump resting quietly in Italy"), the London Legacy Development Corporation attempted to reuse about one-third of all structures created for the games. 

Naturally, this inspired me to find the link between the Olympics and software development.  

One commenter Uri writes:

I think there is much more than buildings that are left behind. There is huge pull of amazing skills, knowledge, technological advancements which if planned and used properly can prove to be a bigger and much more sustainable contribution. However, putting these into use may require more thinking and planning then the reuse of infrastructure.

I have been enjoying Alan Cohen's A Deep Breath of Life. I read it every morning with pen in hand, never failing to find at least one or two profound sentences to be my watch-words for the day. One of the July writings contains this quote: "Only infinite patience begets immediate results."  David writes about the perils of rushing through life, and how a lack of patience can causes us to create unnecessary chaos in our daily rounds. He writes, "Rushing never improves the quality of our life or the results we seek; to the contrary, it muddles our vision and causes us to make errors that cost us twice as much time and energy to repair."

One of my first thoughts was about my work at QSM, and how SLIM-Estimate demonstrates the power of patience in software development. Is it possible to exercise patience when there are important business objectives and profit margins to achieve? The Putnam software production equation, backed by 30 years of industry data, shows that relaxing the project schedule gives the best “bang for your buck” to produce value for your customers.

QSM is pleased to welcome J. D. Ottenbreit and James Heires, two recognized industry experts, to our growing professional services team.

An accomplished business leader with 15+ years of technical and functional experience that spans the commercial, government and academic sectors, J. D. Ottenbreit specializes in client and large account management, project/program oversight and control, the full software development lifecycle, quality assurance, business process redesign, as well as strategic planning and execution. He has led teams both domestically and internationally as part of a former Big Four corporation, a Fortune 50 company, and as an advisor to various cabinet level government agencies and departments.   

Jeff will lead the QSM commercial consulting line of business where he and his team leverage our SLIM Suite of Tools and deep business insights to provide software modeling, project stewardship and best practice, metric and benchmark studies for application development and IT decision makers. 

Jeff is a certified Project Management Professional (PMP) and trained in the Information Technology Infrastructure Library (ITIL) methodology and Carnegie Mellon’s Software Engineering Institute’s Capability Maturity Model Integration (CMMI) model. He holds a MBA in Management Information Systems from Sacred Heart University, a Bachelor of Arts from the University of Saskatchewan, and is a graduate of the Yale School of Management Strategic Leadership Workshop. 

In spite of 30 years of structured programming, CASE tools, OO development, 4th GL languages, CMMI, and PMI, the failure rate for larger projects has failed to respond to all of this love and attention. We normally think of failure as a negative thing; but it can have its upside. Saddling a competitor or enemy with a doomed project could stain their career or at the very least inflict a high level of pain on them. A CEO about to retire, or whose focus is on near term stock options, may be able to boost quarterly profits by continuing to add staff to a doomed effort:  one for which the customer pays for the added staff, of course.

Since failure is a constant, here is a management guide on how to assure failure. While any one step in the process can be overcome, taken together they create the perfect software project storm.

Step 1: Start work as soon as you can

Come on. You don’t really need to spend all that time in requirements meetings and documenting assumptions. Real projects take the ball and run.  Be sure to begin coding as quickly as possible. Call it prototyping if you will; but do get started. You can always circle back to tweak things if needed.

Step 2: Estimation is overhead

Nothing is more frustrating and time wasting as having to go to some external group who know nothing about your project and have them tell you how long your project should take, how many people should be on it, and what the trade-offs are. What can their mathematical models possibly know about your project? A good end run around this situation is to create a project plan and call it your estimate. Make sure that it is very detailed and contains decimal points, since these will make it more difficult to challenge.

Thomas C. Redman recently wrote about data quality on the Harvard Business Review blog.  In his post, he creates a vignette of an executive who finds an error in data provided by the "Widgets Department" for an important meeting. The executive corrects the error, the meeting is a huge success, and the story ends there. Redman argues that someone should have gone back to the Widgets Department to report the error, not to complain that the error could have ruined the presentation, but rather that it could ruin the next person's presentation.

The hardest part about database validation is not reviewing every individual project, but rather, determining if the information on each tab is correct. Sometimes, it's easy to tell that the organization name is spelled incorrectly, other times, it's difficult to discern if a labor rate is incorrect. Having a well-documented database is important, not just for your own use, but for whatever you plan on using it for next.  For example, if you plan on making custom trend lines, but you recorded that it took you 31 man months instead of 3.1 man months, that would have a disastrous effect on your trends! It's obvious that the error would need to be recorded, but it's also important to report the error to whoever prepared the data so that they can check the rest of the projects in the database for the same error. 

Redman suggests creating an office culture which promotes the following three points:

David McCandless gave a TED talk  in July 2010 that focused on pairing data and design to help visualize patterns.  In his talk, McCandless takes subsets of data (Facebook status updates, spending, global media panic, etc.) and creates diagrams which expose interesting patterns and trends that you wouldn't think would exist.  Although the focus of McCandless' talk was about how to effectively use design to present complex information in a simple way, I was struck by his own claim that data is not the new oil, but rather that data is the new soil.  For QSM, this is certainly true!

QSM maintains a database of over 10,000 projects with which we are able to grow a jungle of ideas, from trend lines to queries about which programming languages result in the highest PIs.  With  the amount of soil that we have, we are able to provide insight into the world of software, just with the data that is graciously provided by our clients.  By collecting your own historical data in SLIM-DataManager, you can create your own trend lines in SLIM-Metrics to use in SLIM-Estimate and SLIM-Control, analyze your own data in SLIM-Metrics, tune your defect category percentages and calculate your own PI based on experience in SLIM-Estimate, and much, much more.