Larry Putnam Jr's blog

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

It may seem absurd to think about working an 18-hour day, but it happens all the time in the software development community. If managers don’t accurately estimate project schedules based on a clearly defined scope of work, managers and their development teams may find themselves working long days to deliver on promised deadlines and deliverables.

Being overworked in an environment where a project is running over schedule can also lead to the delivery of a defective or flawed product, which is bad for both the development organization and the business unit for which the product is being developed. One article that I read recently states that time pressures cause employees to cut corners and that the 18-hour workday does not allow for forward or creative thinking. This can be disastrous to an organization that values both the quality of work and the out-of-the-box thinking of its development team.

Our team has been working hard to make sure we’re making your job as a project manager, estimator or company executive as easy as possible. QSM is more than an estimation company, providing predictive analytics to support fact-based decisions and realistic resource demand predictions for enterprise level capacity planning. This means that no matter where you are with your project or portfolio, you can find the information you need quickly and easily.    

So, as you may have noticed when you came to our site today, things are looking a little bit different, as we’ve rolled out our new and improved website! Our hope is that you’ll find it incredibly easy to navigate. If you aren’t exactly sure where to start, right on the home page you can now select a starting point by clicking on any of the following buttons:

• New to QSM
• Familiar with QSM
• QSM for Government

At a quick glance of the homepage, you can also now get a brief overview of QSM and the industries we serve, and access our blog, news, and client list. 

One of our primary goals for the new site is to help each and every visitor understand the problems we solve, so they can better serve the companies, organizations and government agencies they work for.  This new drop down menu includes the following:

I recently came across this blog post by David Gordon and I believe it nicely summarizes the problem many C-level executives find with the #NoEstimates agile view. At the end of the day, they need realistic numbers in order for their organizations to make a profit and remain competitive in their markets. It's simply not enough to start development without some sort of upfront plan as to how much the overall project will cost. Gordon gives a nice analogy:

Now, picture a carpenter who has been asked to bid on framing a group of houses. He replies that he can’t tell how long it will take, because his crew hasn’t built that model before. But if the home builder gives them, say, $400,000, they will work diligently, and when the money runs out, they can decide together whether to put more money into the construction. You’re probably thinking that the builder won’t ever do business with that carpenter, and neither will anyone else in town. But that’s because the carpenter isn’t an employee—he has competition. This helps explain why certain software developers think #NoEstimates is a fine idea—they don’t perceive that they have competition.

Unfortunately for developers, this is not a sustainable way of operating - as many organizations continue to outsource more and more positions, developers will need to be able to justify their work as a business case. Gordon argues it's worthwhile for developers to learn software estimating best practices and to "...take some time away from learning the newest cool development tool to become viable as a contingent worker." I have to say that I agree.

Software size, the amount of functionality in a given software release, is arguably the most important of the five core metrics of software estimation.  There is little point in tracking effort, duration, productivity and quality if you are unable to quantify what you are building.

Yet, despite its critical importance, software sizing is often a difficult concept for many to understand and use properly in the estimation process.  Sometimes a picture is better than 1,000 words.  With that ideal of visual simplicity in mind, we developed a software sizing infographic that helps explain:

• Why we care about size
• Challenges in sizing
• When size should be measured during the software development life cycle (SDLC) to narrow the cone of uncertainty
• The difference between functional and technical size 
• The most popular sizing methods and when to use them

The infographic begins by introducing the five core metrics of software estimation (size (scope), schedule (duration), effort (cost), quality (defects) and productivity) and the nonlinear relationship between them.