IT budgeting is anything but simple, so why do so many organizations do it in an overly simplistic way? Instead of relying upon detailed task-based spreadsheets and wild guesses, IT budgeting should be leveraging historical data and predictive modeling. This webinar will discuss the business process and application of estimation to the challenges of building the annual IT budget. Presented by QSM's Larry Putnam Jr. on October 11 at 11:00 AM EST, this upcoming ITMPI webinar will focus on how this process can support the following aspects of portfolio management: Pipeline - Demand Management, Risk Management, Resource Management, or Financial Management. Larry will demonstrate how a macro-level estimation process can leverage the very basic information typically available early in the development cycle to generate release level budgeting information. He will then show how to aggregate the releases to provide portfolio level assessment and adjustments that will conform to business level constraints. This webinar will be useful for anyone involved in or responsible for building the annual IT budget.
Enterprise IT teams have been searching for years for the Holy Grail of software development: the greatest possible efficiency, at the least possible cost, without sacrificing quality.
This endless search has taken many forms over the years. Twenty years ago, development teams turned to waterfall methodologies as a saving grace. Soon after, waterfall begat object-oriented incremental or spiral, Rational Unified Development (RUP) practices.
Today, it’s agile development’s turn in the spotlight. C-suite executives are investing huge sums of money to develop their organizations’ agile methodologies. They’re also committing significant resources to train employees to work within agile frameworks.
Yet many projects are still failing, clients remain unsatisfied, and IT departments are often unable to meet scheduling deadlines. Why?
It’s the staff, not the method.
Whenever a project falls behind schedule, the natural inclination is to add more staff. There’s a belief that doing so will accelerate development and, ultimately, help the team hit their deadlines.
QSM is pleased to announce Keith Ciocco will be presenting "Cost Optimization for IT Portfolio Budgeting" on Monday, October 2 at 6:10 PM on the Emerging Technologies Stage at the upcoming Gartner Symposium/ITXpo. This presentation will highlight cost optimization techniques in the annual IT budgeting process. Instead of relying upon detailed task-based spreadsheets and wild guesses, attendees will learn how to leverage historical data and predictive modeling for more accurate and cost-effective IT budgeting.
Additionally, QSM will be exhibiting SLIM tools and consulting services in the Emerging Technologies Area. Stop by booth ET14 to get a live demo and learn more about our IT budgeting and demand management solutions.
It’s that time of year again for many C-level executives: time to figure out the IT budget for next year. This is to bring the business side of the organization to the table with the technical side to forecast how much IT is going to spend. It can be a complicated process, but there are ways to make it easier and more accurate; and there are ways to save a lot of time and money. The challenges often relate to short planning time frames, minimal information available to generate accurate forecasts, political agendas within the organization, and, unfortunately, only a small number of estimation methods in place. But there are tools and processes available to help face these challenges. Here are the basic steps that we recommend for cost optimization in the budgeting process.
Start by analyzing the historical data that is available. The process can be streamlined by focusing on the core metrics within the organization. This data can include release level size, effort, staff, and duration information. Historical data showing typical effort by role by month spending is also valuable to leverage. Ideally, this type of data should be captured on 8-15 projects.
The next step is to pull together scope level sizing data on projects that are being considered for the new year. This information can include epics, themes, user stories, business requirements, or use cases, to name a few. The goal here is to get as close as possible to determining how much work needs to be done on each release in the pipeline. Once there is a large enough sample of data, then release level estimates can be created for the coming year. There are tools available to help streamline this process and the best ones allow for risk mitigation and sanity checking with historical data.
QSM recently published the seventh and final article in the QSM Agile Round Table series. The QSM Agile Round Table was formed to discuss the role of estimation in agile environments. QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment. Participants had several questions about measuring effort and productivity, and whether there are special issues around how to define and collect these metrics in an agile environment. In this article, Andy Berner identifies best practices for measuring effort and productivity in agile and discusses how the two are related.
We are pleased to announce that QSM Lead Trainer and Senior Consultant Pam Simonovich will be presenting a workshop focused on applying function point rules to emerging technologies at the upcoming ISMA 14 on September 13. She will also be giving away VR Elegiant Virtual Reality Glasses to one lucky participant!
Today’s sizing expert must be able to accurately apply function point counting rules and SNAP counting rules to a variety of software environments and technologies. This hands-on interactive workshop will prepare you to apply counting rules to the ever-popular gaming Industry and promises to include such technologies as Artificial Intelligence, Virtual Reality, Cloud computing, etc. The contents of the course will be reinforced with examples and hands-on case studies.
The workshop schedule will be as follows:
Usually when I am online making a payment or using social media, I am not thinking about software quality. But lately I feel like I have been encountering more bugs than usual. From activities like clicking on a link where I should be able to input my payment information, to doing a search and receiving an error message, or being redirected to a completely different page which had nothing to do with the mission I had set out to accomplish. These bugs are sometimes frustrating and I started to wonder what could have been done to prevent these from being released into production.
Since I spend a lot of time speaking with people that manage software projects, I have noticed that quality is often one of the most overlooked aspects of a software system. People I’ve spoken with have mentioned that quality is often not even discussed during the early planning stages of development projects, but it is usually a deciding factor when the software is ready to be released and should be considered from the beginning of the project.
Using a tool like SLIM early in the planning stages of a project can help us with these issues. Not only can it provide reliable cost and schedule estimates, but it can also help estimate how many defects one can expect to find between system test and actual delivery. It can also estimate the Mean Time to Defect (MTTD), which is the amount of time between errors discovered.
QSM recently published the sixth article in the QSM Agile Round Table series. The QSM Agile Round Table was formed to discuss the role of estimation in agile environments. QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment. The previous two articles focused on determining size in a consistent enough manner across multiple products, projects, and agile teams in order to have good historical data on which to base an estimate. They looked at several possible units of measure for software size, including story points, function points, and source lines of code (SLOC). SLIM-Estimate and SLIM-Collaborate permit any of those units, as well as others, to be used for software sizing. In order to use a sizing unit other than SLOC in the SLIM tools, you must assign a gearing factor. For function points, gearing factors are discussed here. In this article, QSM's Andy Berner addresses ways of choosing a gearing factor for story points.
QSM recently published the fifth article in the QSM Agile Round Table series. The QSM Agile Round Table was formed to discuss the role of estimation in agile environments. QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment. This article continues the focus from the previous article on determining size in a consistent enough manner across multiple products, projects, and agile teams so that you have good historical data on which to base an estimate. QSM's Andy Berner looks at other sizing units besides story points, in particular function points and source lines of code.
QSM is pleased to share the fourth article in the QSM Agile Round Table series. The QSM Agile Round Table was formed to discuss the role of estimation in agile environments. QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment. The previous article in this series, “Big Rock Estimation” written by Aaron Jeutter from Rockwell Automation, addressed the question of how to determine the size of a release absent of a “big upfront requirements phase”, and thus when the requirements are only known at a very high level and subject to refinement and change. The next three articles written by Andy Berner will focus on determining size in a consistent enough manner across multiple products, projects, and agile teams so that you have good historical data on which to base an estimate. They will also show how to apply these techniques with the SLIM Suite of products.