Improve

Process defines how a business does business and may include a set of processes such as:

• Software Engineering processes
• Hardware Engineering processes
• Systems Engineering processes
• Manufacturing processes
• Financial processes
• Human Resources processes
• Legal processes
• ………..

Process helps to establish the business culture and then sets guidelines and expectations. Process can be viewed as a methodology that is applied from elicitation of requirements to design through delivery. There are no shortcuts – there are no other alternative methods that a business can adopt that embraces a “cradle to grave” philosophy to ensure quality and profitability with control every step of the way.

We build the business right – through process. We build the right business – with guarantees of product and service quality and customer satisfaction.  Process is the fastest-lowest cost path to get there and know if you are there!

With models, standards, methods and techniques from all parts of the world focused on process and quality it is only fitting that a process improvement manifesto was developed. In September 2009, a group of experts in Software Process Improvement (SPI) from all over the world gathered near Madrid, Spain and shared their expertise and wisdom from their many years of process improvement experience. Sponsored by the European Union, 30 workshop participants brainstormed core values and principles specifically focused on process improvement.

What to use the Manifest for?

Jorn Johansen and Jan-Pries-Heje, the leaders and chief editors of the SPI Manifesto put forth a reminder on what to use the manifest for. You can use the manifest to obtain knowledge of SPI. It will help you remember what is important about software process improvement. Each value and the consequent principles are written so you can easily place yourself into the problem and context. Short explanations for each value are provided that can further augment your understanding. Each value also has some relevant examples that will make it easier to learn and remember the values and principles.

You can use the SPI Manifesto when you are responsible for planning a SPI project. The third manifest value states that SPI is actually really about change. You can apply these SPI Manifesto principles in your organization’s process improvement project that will support the necessary corresponding change.

Values

• People – Must involve people actively and affect their daily lives not to be focused on management alone
• Business – What you do to make business successful – this is not about living to deploy a standard, reach a maturity level, or obtain a certificate even though it can certainly help do all of those things
• Change – Process improvement is inherently linked with change – we realize and accept that we cannot continue to live as we do today – we must change – perhaps a little or perhaps a lot

Principles

People

• Know the culture and focus on needs
• Motivate all people involved
• Base improvement on experience and measurements
• Create a learning organization

—        Business

• Support the organization’s vision and business objectives
• Use dynamic and adaptable models as needed
• Apply risk management

— Change

• Manage the organizational change in your improvement effort
• Ensure all parties understand and agree on process
• Do not lose focus

You are invited to read the details behind these Values and Principles statements located in the body of the SPI Manifesto and share your comments back with us. Do you agree? Do you disagree and why? Do you think something critical was overlooked and should be added?

We are interested in your comments and inputs – after all process improvement is continuous…………………..

Tim Kasse
CEO & Principal Consultant
Kasse Initiatives LLC

“The roles of the Project Manager and the Systems Engineer are often combined and imposed on the already overloaded Project Manager. This is encouraged by contracts that do not understand the criticality of systems engineering and do not recognize the need for both a Project Manager and a Systems Engineer” – Tim Kasse – 2004

After years of being involved in systems and software engineering and conducting hundreds of assessments, I am astonished at what project managers tell me they are responsible for. I am more astonished that organization’s think that if they just announce that a project manager can be a multi-faceted person, he or she will magically be able to do all that is asked of them in an unquestionable manner. One assessment revealed that a Project Manager was responsible for (No Joke):

• Planning and Control (Management part) of project including the soft side or people side
• The technical management of the project – This means they were supposed to be able to completely fulfill the Systems Engineering role
• Quality Assurance – Conduct the quality assurance functions on their own project
• Configuration Management – Perform the configuration management functions required for Developmental control of configuration items and ensure a smooth hand-off to the Organizational control part of configuration management
• Systems Test – As they normally did not actually do any coding or build any other engineering components, it was thought that the Project Manager should be able to conduct the Systems Testing as well

There may have been even more responsibilities but those mentioned above should be sufficient for this blog. My response to the report given by those project managers: Can any of you really perform all of those tasks with efficiency and effectiveness? Because if any one of you can, I will hire you immediately and pay you the highest salary of your imagination. Why, because we are going to make millions off of you!!

If you are a Project Manager please let me know what Project Management responsibilities you have been given responsibility for. How does your list match up to the one given above?

Project Manager

The project manager is the head of the project and has the ultimate responsibility for the planning and control of everything related to the project. The Project Manager must provide direction to the project team and be able to answer questions including:

• For whom do I work?
• What is expected of me?
• Why is it expected of me?
• What tools and facilities are available to me?
• How do I do what is expected?
• What training is available to me?
• What must I produce?
• When must it be produced?
• Who do I give it to?
• How will my product be evaluated?

The Project Manager is the DRIVER and as such takes on the responsibility for many diverse tasks including:

• Lead the project team through the process of creating and executing the project plan
• Mold the project members into a project team
• Obtain approvals for the project plan
• Issue status reports on the progress of the project compared to the plan
• Respond to requests for changes to the plan
• Facilitate the team process, using trained and experience in interpersonal skills
• Remove obstacles for the team so they can do the job they are asked to do
• Act as the key interface with the project sponsor
• Act as the key interface with the project customer
• Ensure that the relevant stakeholders are involved throughout the project lifecycle as required
• Call and run regular project meetings
• Issue the final project report
• Capture lessons learned and update the process database

Systems Engineering combines basic engineering principles and a method of thinking together with a roadmap that guides a project toward a functional development of complex systems. It requires the interaction of technology, the organization, and the environment.

Hence one can look at Systems Engineering as the management technology that controls a total system life-cycle process, which evolves and which results in the definition, design, development, and deployment of a system that is of high quality, and is cost-effective in meeting the user’s needs.

Systems Engineers

The Systems Engineer is typically responsible for:

• Identifying the need and the system opportunity by matching need and technical feasibility
• Being the link between customer needs and system idea and design during the entire process of system creation
• Developing a set of system and functional requirements based on customer needs, wants, constraints and interface requirements
• Dividing and allocating the functional requirements into different subfunctions and modes of operation
• Serving as the lead in envisioning the system’s operational concept and create the link between the system’s requirements and the system’s configuration
• Designing the system architecture based on the operational concept and operational scenarios
• Collecting data from various sources, perform modeling and simulation and analyze them as a basis for decision making
• Determining if the system is designed to its requirements
• Testing and verifying that the system, as built, will meet those requirements as designed
• Conducting technical and tradeoff analysis leading to the resolution of technical problems at different interface points
• Conducting risk assessment on the various system elements
• Seeing the entire picture and how each part is contributing to the performance and feasibility of the system as a whole
• Coordinating the work of the various disciplines involved and manage the interfaces among them so that the result is an overall optimum system
• Evaluating or supporting the performance and qualifications system integration and of the final system through testing and simulation

If you are a Systems Engineer please let me know what responsibilities you have and the relationship you have with the Project Manager. How does your list match up to the one given above?

System evolution has and will require the technical guidance of the Systems Engineer from cradle to grave and the management guidance of the Project Manager to ensure the customer requirements are evolved into a deliverable product.

Share your Systems Engineer vs. Project Manager experience.

NOTE: Tim Kasse’s B.S. degree was in Systems Engineering. He has been involved with various software, systems, and hardware projects throughout his career.

Is an assessment really the most appropriate step in getting an organization’s process improvement initiative started?

One of the more important steps in starting a process improvement initiative is to determine the appropriate tasking and the scope of the process improvement program. There is great temptation for an organization to attempt to take on too much too fast, especially if it feels that it must catch up to its competition. For example, an organization will assess its capability against all of the Process Areas (PAs) of the CMMI and try to set up Working Groups and Action Plans in a broadly based approach to implement multiple levels of PAs at the same time. While it is natural to want to initiate a program quickly, it is important for an organization trying to get a process improvement initiative started to be as realistic as possible in these beginning stages.

Many Lead Assessors / Lead Appraisers push organization’s to undergo an assessment straight away to find out where their current process capability is. Is that appropriate for the organization? Or is it a need of a Lead Appraiser to get his/her checkmark to keep governing bodies, such as the SEI happy with the number of assessments conducted within a given time period?

It is my opinion, after 20 years of involvement with the CMM, CMMI and assessment, that it might not be appropriate for an organization to conduct an assessment right away. The organization might want to focus on only a few areas to get its process improvement initiative started, show positive results and then expand.

There are many factors that must be taken into consideration when an organization is trying to establish its organizational process. What process improvement entry strategy an organization chooses depends on a number of factors, including the following:

What possible process improvement entry strategies have helped your organization or have you recommended? Send me your comments and then download the paper, “Entry Strategies Into the Process Improvement Initiative” written by me and my dear friend and colleague, Dr. Patricia McQuaid of Cal Poly State University and compare. The original version was written around the CMM but has been updated to CMMI v1.2 for this offering. Send additional comments if you want. We are always interested in your opinions and points of view.

Best Regards,
Tim Kasse
CEO & Principal Consultant
Kasse Initiatives LLC

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!