When I was at the University of Miami ( Mathematics major, had a great time, if I had unlimited funds I'd still be there), one of my roommates was an Engineering major ( 5 years, 25 pounds of books, studying all the time), and one was a Computer Science major ( boxes of cards, spent all his time at the computing center, looked like he was facing the headsman when he tripped and two boxes of punch cards spilled all over the sidewalk). Needless to say, I was happy to attend the presentation by Dr. M. Lewis Temares, VP of IT and CIO of the U, and past Dean of the College of Engineering. Patrick O'Toole, one of the leaders in implementation of Process Improvement and senior consultant at PACT gave one of the best common sense presentations I've ever attended, And Bob Lawhorn, CTO at CAI, another of the long time practitioners of IT Management, made all of us process geeks take another look at this from the business side.
I'd like to talk a little about the presentations:
Do's and Dont's of Software Process Improvement
The hyperlink to Pat contains links to 22 articles on the Do’s and Don'ts, it’s worth going there and reading all of them to get a more in-depth view of this topic. I can’t and won’t blog here about all 22 articles (even Pat skipped a few in order to fit his hour long presentation) I’ll just try and hit a few highlights from the experience.
There must be some reason why management is looking for process improvement. Senior management’s involvement and commitment are indispensable to the process. Start with reasonable expectations with demonstrable positive outcomes for the business. Remember, the process is the tool, not the goal. Interestingly enough, Process Improvement is itself a process. Remember that no two organizations are completely the same and no two organizations are completely different. Predictability has more value to senior management than almost any other value derived from process improvement (I can vouch for this from personal experience).
Measurements are critical, if you don’t have metrics, start now. Look at the data being collected and make sure it’s useful. If it’s not, start collecting useful data. It you don’t start collecting data, you’ll never have any and without a baseline to measure against, how will you determine the effectiveness of the process change.
The Politics of Software Metrics
Ed’s point is that no matter how you present the introduction of performance measurements, the mere fact that you are trying to measure will be perceived by those being measured in many ways.
Some will feel threatened. All will be affected, if only by the time required to report the data. Presentation of the reasons for introducing the measurement are of paramount importance and must have a visible value to the organization, whether it’s for improved forecasting, scheduling, estimation or whatever. Whatever gets measured better be used. There are some basics: effort, size, overtime, defects, turnover, etc…
Sometimes, people lie, or leave out something and metrics can outlive their usefulness. We should be sensitive to the climate and remember that actions speak louder than words. Don’t ignore human nature and pay attention to feedback loops.
This was a very intense presentation and was limited by time, but as you can see from the image above, it was full of information.
Measurement, Metrics, and Industry Leadership
It seems that when we look at the best performing companies, we are also looking at the companies with the best knowledge of how they are doing compared to both themselves and to the industry at large. Why is this a surprise? If you don't measure, how do you know where you are?
Wow, was this an infomation filled presentation! Capers first talked about different measurement methodologies, FPUG, ITIL and Balanced Scorecard. Not all are mutually exclusive. Difficult measurements include size, quality and the data cost of ownership.Value measurements can be either financial or non-financial. How do you measure the value of your reputation for instance, or customer good will? Do you measure risk, and if so how? The best value comes from improving process in defect removal, all the way from reporting to requirements, design, implementation, testing, documentation and training. Quality improvements result in the highest ROI of all process improvement initiatives. Even so, high quality programs may be penalized because their cost/defect may be so high. This leads to the guidance that in all process improvement initiatives, reasonable goals produce the best results.
Using Students to Predict Future Trends in Technology
Dr. M. Lewis Temares
The pace of change in technology is increasing rapidly and the applications we are developing to meet today's current needs will not be the applications that will be attractive to users in the future.
Those of us who move to new technologies are different from those who grew up with them. Who better to keep us up to date than students. They are the early adopters. They are the discoverers and the ones who will decide which technologies will prosper and which will fade away. Social networking and twitter are here now and we need to be able to accommodate them. We'll need to be ready to adopt whatever comes next. I have as one of my developers a current college student and plan to always have available as new entry level developers or interns either students or recent graduates, not only are they up on the latest technology, but they are eager learners and still have all the great fun development discoveries ahead of them. They are going to be our employees and customers in the future in any event, so we'd better be ready for them.
Transforming IT Management for Dramatic Business Success
Bob's talk took us through the steps we'll need ot go through to transform our processes, from visibility through control, optimization and finally transformation.
Since efforts to reduce rework result in the highest ROI, it is the best place to start, all the way from reporting, through requirements analysis, design, execution, integration, testing, training, documentation & deployment. Everyone know how costs increase exponentially the further down the line the problem correction occurs. Start with Support & Maintenance, it's the biggest part of the budget, the code is already in use, it's easier than new development ( depending on the state of the code), it's faster & it pays recurring benefits.
This has been just a smattering of what was covered in this seminar (which was webcast live). It would take several articles to cover any one of these presentations. A few of the major points from this day include:
- The process is the tool, not the goal.
- Predictability has more business value than almost any other benefit from process improvement
- You can't manage what you don't measure.
- Measure what matters.
- Use what you measure.
- Respect people's time.
- Actions speak louder than words.
- Don't ignore human nature & pay attention to feedback loops.
- Keep yourself in tune to new technology and the outlook of native users.
- Quality investments give the best bang for the buck.