QSM is pleased to announce the release of SLIM-Collaborate 3.0, the web-based, software-as-a-service version of our trusted software estimation, tracking and benchmarking suite. With more advanced workflow capabilities, the updated version of SLIM-Collaborate enables more efficient communication between stakeholders throughout the estimation process. Additionally, the demand resource capabilities added in SLIM-Collaborate 3.0 make it easier for users to identify staffing needs and allocate resources to a software project.

Highlights of the new capabilities in SLIM-Collaborate 3.0 include:

Larry Putnam, Jr. was recently quoted in 'Framework and Standards Are the "Essence" of Agile at Scale,' an article published in SD Times. The article consulted other industry experts such as Ivar Jacobson, Matt Schenck, Dean Leffingwell, and Ken France on best practices for implementing agile at scale. Larry's advice below.

Agile estimation is the key to a successful SAFe implementation
With all of the benefits of SAFe, getting it right is key. Using agile estimation can help.

“For organizations that are implementing SAFe, they’re really trying to coordinate a lot of different stakeholders within the organization and the real benefit they’re looking to get out of it is a much more nimble delivery,” said Larry Putnam Jr., co-CEO of QSM. “To be able to do that, we’ve got all these different stakeholders that we have to coordinate. That becomes really complicated and estimation is kind of the communication vehicle for these different stakeholders.”

Putnam explains that the highest level of an organization is the business and its stakeholders. The stakeholders or senior managers within an organization need to ask in what direction the business needs to go and how software will support that. These needs are usually articulated at a high level, said Putnam.

“Those are going to get apportioned across different value streams, and they’re really looking at the whole portfolio of what’s going on within the enterprise,” Putnam said. “In order to implement all those capabilities the business wants, you’ve got all these different cross-functional teams that are working on different pieces of the system.”

At QSM, we understand the importance of looking forward, but we also strongly believe in sharing the insights and advice we’ve gained from our past experiences. That’s why we gathered our best and brightest team members to provide their top five pieces of advice for successful software development in 2018.

1. Use verified project data as a baseline.

Too many organizations think of “estimation” as really just bottom-up planning—dividing a software project into its component tasks, and then trying to pair each task with plausible time and resource numbers. They’re left with “point estimates,” or single values, that don’t account for the inherent uncertainty surrounding a project’s size, scope and productivity. Point estimates can lead to inaccuracies that can ultimately cause projects to run over time and budget.

Instead, organizations should base their estimates on real, verified project data. These “top down” estimates should be completed long before prohibitive schedules, budgets, and task lists get cemented into place. Organizations that use this approach are able to account for any changes in scope or requirements early on and adjust their quantitative estimates as needed, leading to better and more accurate forecasting.

- Larry Putnam Jr., Co-CEO, QSM

2. Fill in the information gaps in your software estimation process.

In my daily work life of supporting my clients, I’ve seen the IT project estimating function reside in many different areas of organizations.   Some groups have this function situated in a core group, such as an Estimating Center of Excellence, PMO or Delivery Excellence group.  These teams are responsible for either creating estimates for the organization after being fed some goals/assumptions, or vetting existing estimates born elsewhere to ensure they are in line with the business’ goals without compromising, as best they can, budget, schedule or quality.

Conversely, I’ve worked with organizations in which the project estimation function is supported by organizationally dispersed estimators who are busy with their other tasks.  Decentralized estimators typically serve a sole siloed division with not much interaction outside their team.  Like the bigger shops, these folks are funneled project estimates to be sanity checked and render their analysis with recommendations for adjusting the estimate if it seems out of line. 

Both scenarios above share a common thread – the estimates, regardless of their origin, have an impact on, and are influenced by, a wide breadth of people.  We at QSM call these people stakeholders, contributors, influencers etc.   They all have some kind of investment in the estimate that is important to them.  What if we could involve them in the estimating process?  With more communal agreement on inputs, there won’t be as much rework of the estimate later, when otherwise uninvolved people see their interests aren’t represented.  With everyone feeling they have a say in the estimate, smoother seas are at least more possible.

In 1990, former General Electric CEO Jack Welch wrote a prophetic passage in the company’s annual report. “Our dream for the 1990’s is a boundaryless company…where we knock down the walls that separate us from each other on the inside.” However, large enterprises who have attempted to live by Welch’s dream remain hampered by set hierarchies: development teams and product owners exist on one level, business management and system engineers on another, while enterprise architects and portfolio managers reside atop the organizational food chain. Employing a top-down estimation approach to project management can help organizations overcome boundaries and satisfy the three V’s of corporate success – vision, value, and velocity. This article, originally published in ISV Insights, takes a closer look at how this approach can work for software companies, particularly larger organizations, to help them improve project management, team collaboration, and development practices.

Read the article!

It’s a story we hear a lot in the software business these days, especially with agile development. New functionality is needed within a certain amount of time and within a certain budget. 

Some might say, "no problem! We can figure it out as we go along." They might feel comfortable because each sprint has already been set in stone.  But there are business-related questions that need to be answered before sprint-level planning takes place and before we commit to goals that might not be achievable at the release and portfolio levels. Should we agree to do this project? Can we really get all of the work done within our constraints? Will the software be reliable at delivery? How does this project impact our annual and multi-year forecasts? 

This is where having reliable big picture numbers can be helpful. Wouldn’t it be great if senior management and the technical team were on the same page early? There are empirically-based estimation tools that can help. The naysayers might say that the technical requirements aren’t firm enough to come up with early estimates before the sprint planning takes place. But the fact is that some of these models (the good ones) allow for managing uncertainty and they do it based on historical data. The slide below shows a summary example of a release-level estimate for cost, duration, and reliability.

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

Large-scale IT infrastructure projects require an enormous amount of planning, design, configuration and testing to ensure that everything is working correctly and properly transitioned once the work is done. This takes time and resources. Like their software counterparts, IT infrastructure projects are more likely to be successful — more efficient, secure, and reliable — when accompanied by robust estimation and planning processes. In this article for ProjectManagement.com, Larry Putnam, Jr. and Joe Madden identify best practices for applying parametric estimation to IT infrastructure projects.

Read the article!

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 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.