October 2013

October 2013

Ask Carol: If IT's Important, Get a Second Opinion

QSM is hosting a new free advice column for software professionals who seek help to solve project management, communication and general software project issues. The first few scenarios are based on questions we receive all the time. Carol Dekkers is a QSM consultant and IT measurement and project management expert who speaks internationally on topics related to software development. Send your questions to Ask Carol!

Dear Carol:

I am a seasoned software project manager who continually gets blamed when my projects come in late and over-budget.  I’ve worked the last 8 weekends with my team to deliver software for my customer and no matter what we do, we can’t seem to catch up or curtail the spending. Now my team is even turning on me saying I should have known that management would get angry, when they were the ones who imposed unrealistic deadlines and keep changing their minds about what functions they want delivered first.  We’re all ready to throw in the towel, but we love our jobs and are doing the best we can.  Help!

– Overworked and Frustrated in IT land

Dear Overworked:

The first thing I can tell you is that you are not alone!  I know that this might not make you feel better, but even the best and highest paid project managers face the same issues on a day-to-day basis.  The best piece of advice I can give you is “if it’s important (as IT projects are!) – always get a second opinion.”  This is what we do in life – if you go to a doctor and he tells you that you need knee surgery, you always get a second opinion.  We need to apply the same life lessons to our work life!  

Blog Post Categories 
Tips & Tricks Ask Carol

Bottom-Up Estimation? Not So Fast...

One of the most common objections we hear from companies with regard to getting started with top-down estimation is that it’s not needed, because they already have a detailed planning spreadsheet in place. Customers will concede that their estimation practices are not perfect, but that they are working “OK.” But, when it comes to spending your company’s money on software projects is “OK” enough?  

Blog Post Categories 
Estimation

New Article: Ready, Set, Go...and Ready Again: Planning to Groom the Backlog

Planning to Groom the Agile Backlog

In an agile project, the backlog (the prioritized set of requirements) is the main input to iteration planning. For an agile project to progress smoothly, the backlog must be groomed and ready for each sprint. That work must be included in your project plan. In this article, the second in a series recently published on Projectmanagement.com, QSM's Andy Berner gives you five points to consider when planning that work.

Andy Berner is a software engineer and methodologist. He came to QSM in 2012 after over 25 years in both large and small software organizations, including, among others, EDS (now HP), Rational Software and IBM. Based on his experience in almost every role in software development, Andy has consulted with numerous organizations on using software development methods and tools to improve productivity and quality.

Read the full article!

Blog Post Categories 
Agile Articles

Webinar Replay: Bringing Estimation and Business Intelligence to the Enterprise

If you were unable to attend our recent webinar, Bringing Estimation and Business Intelligence to the Enterprise, a replay is now available.

Successful software development estimates depend upon more than just inputs, especially at the enterprise level. They require collaboration between stakeholders, consistency in estimation methods, and historical basis. It's also essential to account for uncertainty and risk. In this webinar, Keith Ciocco demonstrates how SLIM-Estimate and SLIM-WebServices work together to bring reliable business intelligence to the enterprise, while leveraging historical data to increase estimation accuracy and credibility.

Watch the replay!

Blog Post Categories 
Webinars Estimation

Schedule, the Eternal Enemy

“More projects have gone awry for lack of calendar time than for all other reasons combined” - Frederick Brooks, The Mythical Man-Month

These words were penned by Frederick Brooks in “The Mythical Man-Month” over 35 years ago.  Think back to that time for a moment.  The first personal computers were being born as kits assembled by electronic hobbyists.  Serious programmers considered them to be toys.  A good knowledge of COBOL could get you a job just about anywhere.  Computers and IBM were virtually synonymous.  Structured programming was the process improvement silver bullet of the day.  Something called ARPANet, the parent of the Internet, had come into existence.  And software projects experienced serious problems because they weren’t given enough time to complete and test their work.  Everything has changed except for the last item.

Why?

Over this span of time a host of solutions have been attempted with very modest results.  Only the elephant in the living room has been ignored:  since project schedules are chronically and habitually underestimated, why not allocate more time to them at the outset?  The reasons for doing so are compelling:

Blog Post Categories 
Schedule

Flattening the Cone of Uncertainty

Estimation Cone of Uncertainty

image via Techwell

A large part of software estimation is dealing with the unknown. At the earliest stages of a software project, the uncertainty surrounding schedule and budget is at its highest and diminishes as a project reaches completion. In the estimation community, we refer to this as the "cone of uncertainty." Of course, it is at the widest point of this cone where estimation is typically needed. So how can organizations keep their customers feeling secure and informed when requirements are still being flushed out and budgets aren't yet established? In his recent a blog post on Techwell, Noel Wurst identifies strategies for flattening the dreaded cone of uncertainty.

Read the full post here!

Blog Post Categories 
QSM News Estimation

What Can Goldilocks Teach about Software Estimating?

You may not be aware that in 1837 when Robert Southey published his popular retelling of the Three Bears story, the U.S. experienced the “Panic of 1837,” a financial crisis that touched off a decade long recession featuring unemployment, pessimism, lowered profits/prices/wages, and blamed on domestic and foreign origins. While we might consider 1837 a simpler time - it was without modern conveniences like indoor plumbing, the internet, and supersonic travel – some aspects of human behavior and communication aren’t that much different today. I thought about this when I was keynoting the 20th anniversary EuroSPI2 conference (software process improvement) in Ireland, the same week that I read the following in the British press

“The Department for Work and Pensions has dropped a coalition government scheme to avert software disasters from its £2bn Universal Credit programme” forecasting the cancelation of the largest ever agile software development project – a project now four plus years behind schedule with potentially billions of taxpayer funds at risk.  

Blog Post Categories 
Estimation