I’ve just read the speech of Paul D. Nielsen, Director and CEO of the Carnegie Mellon Software Engineering Institute before U.S. House of Representatives.
Very interesting for everyone in the software industry, including the 10 reasons for software acquisitions failures:
1. Technology key to program success is new to the organization
2. Software issues are considered too late in the system-development process
3. Inadequate planning and estimating
4. Size matters – large projects get into trouble more frequently than smaller ones, all projects grow larger over time
5. Software objectives are not fully understood or specified; they change frequently (and grow) during the project
6. Inadequate experiences and trained project management
7. Inadequate process emphasis and erosion of process discipline
8. Inadequate contract incentives to encourage use of proven software engineering practices
9. Acquirers and developers lack experience working as a team or the resources to do so
10. Insufficient senior staff and inexperienced software engineering cadre
In the last 10 years I have found these problems in speeches and presentations, every now and then.
Statistics showed a real improvement in companies that adopted solid models and methodologies. A lot more remain to be done.
I quote what I’ve enjoyed most in the speech:
The “unlimited” complexity of software is neither well understood nor well appreciated by many. Software is not rooted in the physical world like other engineering disciplines–civil, aeronautical, electrical, or mechanical engineering. Without physical constraints, the design space is so vast for large programs that you need strong architectural principles, disciplined processes, and talented people to be successful. The larger the program, the more important this is-and,as you are aware, many defense programs are very large.
Additionally, software is invisible; people don’t buy code – they acquire systems that satisfy requirements. And software is intangible – you can’t touch it or kick its tires. Nevertheless, inmost defense systems, software is critical to the very success of the program. The systems just don’t work without software.
I remember one “funny” experience we had recently in dealing with one of our Government Agencies.
We in Romania have inherited a system in which the company has to paint/stamp an inventory number on each object it owns. So far so good, it doesn’t hurt.
But when that Government Agency requested that we have to paint those inventory numbers on our software, we gasped, and laughed,and choked and got nervous and exploded.
We’ve had this stupid request for years and years in several state owned institutions. Usually we dealt with it by presenting to the bureaucrats a CD or diskette or a licence sheet with an inventory number painted on it. Here Ladies and Gentlemen is your software!!!
This time we debated if we should refuse to obey. Enough is enough. This aberration, a favorite of old bureaucrats, has to stop.Dear all, software is invisible, intangible, is not an inventory object. Give us a break.
Finally, we gave up. Fighting bureaucracy was too much time consuming. We made however a technological progress. At the agency request, we put a label on a computer.
Ladies and Gentlemen, beware, BIS software is inside!
I fully agree with this quote. People CMM has the best practices needed by an organization to attract, develop, motivate, organize, and retain the workforce.
If you are a manager in charge of a whole organization or a team or a HRM Department, People CMM is the model to follow.
People CMM version 2 has just been released.
The People CMM model helps organizations to establish a culture of professional excellence which is the best remedy for brain drain.
Today, People CMM has been implemented in various types of industries (Banking / Financial Services, Government, Insurance,Utilities, IT of course etc.)
The People CMM model must be interpreted flexibly especially when applying it to smaller organizations so that bureaucratic activities are minimized.
Pay attention to the fact that “size” for organizations in Romania (and other small countries) is not the same as in North America. What in Romania we say “large” in USA is “medium/ small”. Only telecom organizations, the first 3 banks, several international companies might be considered “large”.
From the point of view of People CMM Model, most of the organizations in Romania should be considered small/ medium size and as such, the model must be carefully interpreted.
We’ve had enough bureaucracy so far, no need to increase the forest devastation.
I will add this: a collaborative platform, simple to use and affordable yet with a powerful functionality can make the difference between a successful implementation of the People CMM model and a new nightmare in a small/ medium size organization.
As I’m from BIS and I have been using successfully the collaborative software Esfera Suite on a daily basis for more than 7 years so far, I can say Esfera is an interesting option. We are now in the course of migrating the product on Microsoft Sharepoint technology and People CMM proved to be extremely useful in improving the product requirements.
Emilia Dragne
BIS SPI Project Manager
When you start a process improvement project based on CMMI practices, you need a lot of advice. A good consultant is a must. The great www is also full of ideas, some good, some not so good.
🙂
Some advice I found extremely useful is related to process definition. One should keep process definition as simple as possible. Organizing the process documentation in a pyramid like hierarchy is the best.
No need to fill a hundred of pages to describe your process. Nobody will ever read them all. Better start with a high-level description of the process on 3-4 pages. A diagram of no more than 5-7 high-level activities will be helpful for everybody: team, management, auditors etc. Add inputs, outputs, resources,responsibilities and a short description of each activity.
If more detail is needed, move the detail to the next level:instructions. If possible, embed detailed instructions in the tools: templates, electronic forms, online help of the development platform etc. If you really want to write a detailed instruction manual, use graphics, pictures, metaphors. One image is worth 1000 words, ain’t it?
🙁
What bad advice did I find on the www?
One stupid advice was that if you have in your team a very good programmer but who doesn’t obey the established process, you should fire him/her. Now this is like killing the goose with golden eggs. A good programmer can make the difference between a nice software and a nightmare software. A good programmer is not so easy to find. It takes several years to make a good programmer.
So what’s to be done?
First of all, consider the fact that not all human is open to change.
One should discuss the process with the team. Maybe the process is at fault. Automate as much as possible. Embed measurement data collection in the daily routine. Microsoft Team Foundation Server is a good example.
If anything else fails, start negotiating. Explain to the team why some activities, less creative, more administrative are needed.Make sure you have a good case.
Ask the team some simple questions: Do they like working overtime for weeks and weeks? Postponing holidays? Wouldn’t it be nice for everybody if the path of a project can be predicted more accurately? How about creation – the best thing in programming.
Wouldn’t they like more time for creation and less for bug solving?
And so on. Negotiating with genius and artists is tough but this is what makes a SPI project interesting and helps your brain to stay young.
Emilia Dragne
BIS SPI Project Manager
