Improve

At SEPG 2009 in San Jose, I presented a half-day tutorial titled “Change Mangement Tool Kit.”  The idea of “managing change” may be a lot harder than it sounds, thus the idea of developing and evolving a change management tool kit to help people and organizations in their change efforts. What? I thought process improvement based on the CMMI was about building processes, procedures, standards, guidelines, templates, and checklists that could be matched up against the CMMI practices.

Of course if your process improvement focus is strictly on obtaining a Maturity Level 3 or higher, you might think something like this. But here is my challenge. How many of you are in organizations that built action plans based on assessments / appraisals along with other appropriate input and had a major section in that Action Plan that focued on supporting the changes that would need to be made by the people in your organization. You see, if you want to claim, your organization is engaged in a process improvement initiative, you should be claiming in the same breath that you are engaged in improving the people side of the change as well as the technical process side.

What would you think if someone out of the SEPG or EPG or just PG today, walked into your office and plopped down the latest set of organizational processes. What would you think if the person that brought you this latest and greatest work, told you that this represented “YOUR” new way of working and that you and your project were going to be audited against it from now on? You might be a bit upset. After all, you  are an adult and a professional. Right?

Does your action plan have “people expectations” inside of Change Management side? If you perform testing, you are required to have “expected results” inside of your test plan so that the testing results can be compared against the expected results.

This is exactly what should happen in process improvement efforts!!! When you hand out the new and improved process descriptions, you should have the expected people reactions written down along with the risk mitigations to deal with the people reactions. What? People, risk, risk mitigation. Hey, we are trying to reach ML 3! The people should be following the organizational processes – right?

If your organization’s process improvement Action Plan does not have a complementary Change Management component with expected people results, you might want to revisit and revise it. And if you are not sure what Myers Briggs personality types, or birth order, or risk taking personality has to do with the process improvement initiative, you might want to give us a call and ask about what type of Change Management Tool Kit Method Park can help you build and evolve to answer these questions and ensure you are focus on your most important asset, your people as well as your process descriptions.

See You Soon in Prague

Best Regards,

Tim Kasse

I have ignored the AGILE and CMMI wars for many years and have forced myself into the fray in the past year. If you are taking one side or the other, you have little knowledge of history and probable less history of Systems Engineering.

DR. Win Royce developed the Waterfall model in 1970. It was for Systems Engineering not Software. If you know something of building systems, you will know that all systems have a feedback loop. So did Dr. Royce’s waterfall model. But there was something more. Dr. Royce, in 1970 stated that the strict waterfall model where we asked what the customer wanted and then went off and built it with no more customer interaction was not appropriate. He suggested using “prototypes” to help the customer and the supplier build a mutual understanding of the requirements and then start with the waterfall model, still with feedback loops. The Software Community grabbed hold to the waterfall model and gave it the description and bad rap that one must complete the requirements stage before the design before the ………. In 1986, fourteen (14) years later, Dr. Royce was invited to republish his waterfall article, unedited again. The software community still did not get it.

Later, groups just like the Agile group sprung up to let the software world that this Waterfall stuff was bunk and you should have experts who did pair programming and care about the customer. I am one of the original authors of the CMM and have been actively involved with the CMMI for 20 years. In other words from the beginning. While the folks who created the Agile Manifesto did so in part to create controversy, they have seriously missed the point. Read “Balancing Agility and Discipline” by Barry Boehm and Richard Turner with forewords by Grady Booch, Alistair Cockburn and Arthur Pyster. and Scaling Software Agility by Dean Leffingwell.

Here is my point. Some of the Agile points are well made. Large cooperation’s with Lawyers who were hung up on point-by-point contracts caused the strict following of the Waterfall model and made a mess of things. BUT that was not the fault of the description of the Waterfall Model.

As far as Agile techniques are concerned. Sorry to disappoint all of you do or die fanatics. Prototyping was suggested in 1970. RUP corresponds to CMMI Requirements Development pretty well. There was a 14 month study just on this.

Incremental Development. It is a product lifecycle that has been around for 30 years and is embedded inside of the CMMI. So it goes for Evolutionary Delivery, developed by Tom Gilb a zillion years ago.

So Agile, Evolutionary, Incremental, Prototype, RUP, customer involvement, and others key volatile AGILE words have been around for at least 30 years and are part of the process assets described in OPD of the CMMI. They are techniques that projects must apply as they make BUSINESS SENSE!.

CMMI is process oriented but remember the quality of the process influences the quality of the product. CMMI is about using processes to help build quality products and services that satisfies not only the technical requirements but the customer in the operational environment by the end users that have to use it. CMMI is a spin off of Dr.Demings TQM. Dr. Deming clearly states that process should not be done for process sake but for business. CMMI and process improvement and techniques like Agile and others are about Business.

Please come to the European SEPG and hear my talk titles “The Agile View of the CMMI “and learn even more detail. What makes sense given the constraints your project faces. There are projects that last 12 years that the Waterfall Model fits perfectly. There are 7 days events where the 4 months gathering of requirements is stupid. You only have 7 days. YOU MUST USE YOUR BRAIN AND PUT BUSINESS FIRST!