Larry Putnam Jr's blog

Larry Putnam, Jr. recently presented a short tutorial on the benefits of Top-Down Estimation for Software Projects:

• Top-Down Estimation methods provide the data needed to make early decisions because most software project schedule and cost decisions are made early in the project or product lifecycle 
• Savings Associated with Top-Down Estimation
• Top-Down Estimation vs. Detailed Planning
• Sum of the Parts Don’t Equal the Total Time & Effort Required
• SLIM Software Equation Supports Effective Negotiation

Watch the video or continue reading to learn why the QSM SLIM methodology gets you the data and analytics to make software project commitments with confidence.

Benefit: Provides Data Needed for Early Software Project Cost and Schedule Decisions

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.

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.

Successful software execution has always been about having the most relevant data at your fingertips, but there are more ways to gain knowledge beyond graphs and charts. The sharing of best practices and information on the latest solutions, along with access to communities of like-minded individuals, can also be powerful tools for managers responsible for delivering development projects within budget and on-schedule.

At QSM, we strive to provide not just the tools, but also the information needed to help these individuals succeed. That’s why, as we look forward to 2018, we are excited to offer a wealth of resources that go well beyond our SLIM-Suite of estimation tools. These eight resources provide insight and knowledge into some of the most important components of software estimation, including agile development and project management, as well as information specifically for SLIM users.

Agile Development

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.

Successful product development involves aligning the three V’s of corporate success – vision, value, and velocity. Organizations must establish a product development visionthat will help them achieve their goals. Their agile development teams must show valueby delivering products that meet this vision. Finally, these teams must be able to accurately plan and estimate velocity – the amount of work completed during a “sprint,” or specified period of development time -- and factors that could impede that velocity.

Unfortunately, these three V’s exist on different spheres in many organizations. Enterprises tend to be built in silos, with development teams and product owners on a foundational level, product management and system engineers on the next, and enterprise architects and portfolio managers at the top.

Disconnect and misalignment within this hierarchy can lead to inefficiencies and undermine agile development efforts. The point of agile is to be able to iterate product development at a faster and more efficient pace, in turn allowing teams to deliver consistent and maximum business value. That requires communication and teamwork amongst everyone involved in the product development process, including portfolio managers, product owners, solution managers, and more. But scaling agile within organizations can be very challenging -- in large part due to the hierarchies that are especially prevalent in larger enterprises.

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.

QSM recently announced a major update to the QSM Software Project Database, a large and robust body of data that helps software and IT professionals estimate the cost, time and effort requirements for their software and systems projects. As a result, QSM clients and SLIM Suite users can benefit from the most up-to-date and expansive software project benchmarking data, particularly in the agile domain.

With this large update, we’ve validated and added more than 2,500 new projects across nine major application domains (Avionics, IT, Command & Control, Microcode, Process Control, Real Time, Scientific, System Software, and Telecom) and 45 sub-domains. The result is a database with more than 13,000 completed projects, extending what is already the largest continuously updated software project metrics database in the world.

With these enhanced data insights -- all gathered from real-world projects -- SLIM Suite users have access to the most up-to-date software project benchmarking data and can quickly and easily sanity-check estimates against industry data.

IT and Agile Projects Get a Boost

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.

While creating technology is about solving everyday problems, the act of creating technology is about solving design problems. This applies to any type of technology project, regardless of its purpose or size. Organizations must put as much thought and consideration into the design of their underlying IT infrastructures as they do in the design of their software projects. Both require careful sizing, estimation and planning.

Of course, installing, configuring and testing IT infrastructure is different than developing a piece of software. A typical IT infrastructure project could include:

• Server room buildout (clean power, fire prevention, disaster recovery, cabling, etc.)
• Network connectivity (local and wide area network)
• Installation of computer server hardware (can be physical or virtual)
• Configuration of system software on the servers (operating system, database, email server, web server, security template, etc.)
• Configuration of computer desktops, laptops, smart phones. peripherals and other Internet of Things (IoT) devices 

Together, the hardware and software formulate a truly complex system where all of the parts are interconnected.

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.

If you were thinking about purchasing a driverless car, and the salesperson told you that there’s a “slight” chance that the car will fail during transit, would you still feel comfortable laying down your money? Or, if you faced an emergency, would you trust an automated robot to perform open-heart surgery, rather than the hands of a skilled physician?

While these questions might seem like the stuff of a science fiction novel, they’re quickly becoming a part of our normal, everyday world. We’re hearing a great deal about artificial intelligence and how it is replacing tasks that were once done by humans. AI is powered by software, and that software is becoming increasingly vital to our lives. This makes ensuring its reliability more important than ever.

But here’s a sobering thought: right now, IT operations teams are building software that is, on average, 95% reliable out the door. That’s right; today, a 5% unreliability gap is considered “good enough.”

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.

New approaches to software development can sometimes seem at odds with the needs of business customers. For instance, ardent practitioners of the agile development methodology continue to advocate for rapid response approaches and the need for constant iteration to solve complex problems. On the other hand, companies and customers are demanding a strategic approach that provides insight into process, timing, and costs.

So, which of these yin and yang scenarios should developers employ? The answer is “both.”

Enter scope-based software estimation, which I maintain can be a powerful tool to ensure that projects remain on course and on budget. It is possible for schedule and budget estimation to be achieved without sacrificing any of the things that make agile development so potent.

Not everyone feels the same. Some would argue that there’s simply no place for estimates in an agile development world; that estimates cannot coexist with agile or “lean” methodologies like Scrum, which encourage teamwork, speed, and communication without constraints.

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.

As we move closer to the end of the year, many of us are in planning mode. We’re working hard to determine which development projects are going to get done next year, and which ones may have to wait their turn until 2018.

No one should go it alone, though. Business executives need input from IT managers to truly gauge the feasibility of developing the projects that are on their list. Likewise, IT managers need insight into the expectations of business executives so they can produce the products they need.

That’s what makes project portfolio planning so essential. It brings business stakeholders and IT managers together by allowing them to communicate with each other about needs and expectations, and to find common ground that leads to realistic project estimates that help shape the course of successful development for the next 12 months.

It also helps establish a clear product roadmap. It’s not uncommon for organizations to start out with a long list of “to-do’s” every year, but doing everything is simply unrealistic. Therefore, it’s important to identify and prioritize projects that will bring your company the best ROI and help it meet overall strategic goals over the course of the next year.

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.

The term “true original” is used to describe someone who is a trailblazer -- and it describes my father to a T. My dad was an early architect of software estimation, the process of predicting the time, effort, and manpower it takes to complete a software development project.

Thirty-five years ago, my father was a budget director for the Army’s computer programs. He had the unfortunate experience of having his funding significantly reduced when his IT team failed to properly articulate its software development goals in ways that were relatable to leaders. As a superior put it, “Whenever I talk to the IT guys, I hear about bits and bytes, programming languages, and bandwidth, but nothing that relates to time, effort, and cost.”

That comment sent my dad on a mission to develop a software estimation frameworkthat addressed the three points that his boss was most concerned about. He sought to expose what he called “a fundamental law of nature in our software production equation.”