If your production and software development teams are fighting like cats and dogs don’t worry, that’s what you’ve paid them to do.
During a Telelogic teleconference Gartner
Research vice-president and research director Jim Duggan addressed a host of software lifecycle management issues like this one. In recent years software has emerged as a cultural villain of sorts, he said, a title it doesn’t deserve. The culprit for less-than-perfect software is a shift in requirements.
“”From studies we’ve done over the years we’ve determined that in the reasonably stable organization you would expect requirements to change about one per cent a month,”” he says
“”You can play a little statistical game with this and say, ‘We have about a 25 per cent success rate. If I’ve only had about half the requirements right and my project took three years to complete, the business has changed by a third and, gee, 25 per cent is actually pretty good.””
Thanks to changing requirements and technology, software changes are a fact of life. Duggan says for these kinds of projects to be successful team members need a combination of allegiance and intelligence. Those involved need to believe in the importance of the task and be convinced future gain will surpass current pain. Conviction alone, however, isn’t enough.
“”The other half of the equation is that they have to have the training, skills, tools and processes in place that actually make the change able to happen. Organizations have characteristic levels of complexity and change that they’re able to deal with,”” Duggan says. “”If you’re going in a fast-changing business environment you must control the amount of software change introduced because the organization just can’t absorb anything more.””
Over the years, however, these kinds of projects have become harder to manage. Duggan says project plans are rarely explicit enough and not managed closely enough.
“”As part of the response to the difficulty of managing projects, people moved to very short cycles — rapid development — running an average today of six to nine months where a number of years ago, as recently as 1995, the average ran over two years,”” Duggan says. “”Also the group sizes have gotten smaller, dropping from literally hundreds to just a few people per identifiable element, probably under 10. This means that explicit project activities are often dropped because the size of the development team gets small.””
There is also the issue of internal conflict: production versus development.
“”We pay developers and the development team to be innovative, make changes, to introduce a lot of turmoil. At the same time we (say) to the production supervisors, ‘Prevent all change. Make sure the system is always up, always available, always reliable,'”” Duggan says.
But before engaging in any changes Duggan says a review process of the feasibility and priority for the business and technical context must be completed. The goal is to properly define the goal, activities and project plans.
Comment: [email protected]
