Telcordia conducts Software Process Improvement (SPI) consulting to assist client organizations with their internal SPI and Quality initiatives. This paper discusses experiences and lessons learned from a number of SPI initiatives across a range of our client organizations. The organizations range from 50-person IT shops to 2,000+ person IT shops; cultures range from autocratic to “dot com.”
At the end of this paper you will come away with a better understanding of how to better initiate, plan, execute, control, and close SPI projects. You will understand how SPI projects are similar and different from software development projects; and you will have a better understanding of critical issues that must be focused on for the success of a SPI initiative. We discuss the evolution of a SPI project into an overall program that will affect corporate culture.
Exhibit 1. Capability Maturity Model v1.1 for Software Showing Five Levels of Maturity
Software Process Improvement (SPI) projects are the kickoff to an overall program affecting both software engineering and business processes. These projects touch all levels of an organization: Strategic (executive level management), Tactical (middle management) and Local (software practitioners).
Frequently these projects are a melding of the Software Engineering Institute's (SEI) Capability Maturity Model v1.1 (Exhibit 1) and A Guide to the Project Management Body of Knowledge (PMBOK® Guide).
SPI projects encompass technical, managerial and business processes within the organization. Technical processes include project management, coding, configuration management, testing, and others. Managerial processes include program management, project management, review and approval of documents, local practices, assignment of resources and other managerial items. Business processes include interdepartmental processes for approving projects, coordination of interdepartmental resources, budgeting, and Intergroup coordination. At the Strategic level, the focus of a SPI projects evolves into an overall strategic initiative involving culture and business changes that support the overall driving forces of the organization.
Because of the above issues, SPI projects (“A temporary endeavor undertaken to create a unique product, service or result”) will evolve into an overall SPI program. (“A group of related projects managed in a coordinated way. Programs usually include an element of ongoing work.”)
Frequently, we see interest for starting a SPI project from the strategic level of the organization. Surprisingly enough, less frequently, we see the interest come from a frustrated group of local or tactical level folks in the IT organization. Quite frequently no one within the organization realizes the commitment, duration, level of effort or culture change required to successfully complete and leverage a SPI project into an overall program. Most believe that a tool can fix the overall software processes and the organization assessed at SW-CMM™ level 2 within six months! This is possible, however highly improbable. Education, creation, socialization and continued improvement of the new process and culture are key. Each level (strategic, tactical and local) must be given an overview of the SPI project and how it evolves into an overall program.
SPI Projects: Initiate Through Close
SPI projects utilize the same project management process groups (initiate, planning, execution, control, lose) as any other project. Because SPI projects have equal footing in both the technical and cultural arenas, there are some nuances to them.
Initiate
For a SPI project/program to be successful, you need support from all levels of the organization: Strategic, Tactical and Local. During the Initiate Phase, authorization must be obtained from the highest levels. Time must be spent to educate and set expectations as to the duration, level of effort and return on investment (ROI) and the ROI components. We have found this issue to be the most critical, not only obtain commitment, but also to maintain it through the life of the project and evolvement into a program.
Strategic
Developing and Maintaining Support
We cannot stress this enough. Development and maintenance of executive-level support is critical to the success of a SPI project and program. Often developing the support, like starting a diet and loosing weight, is easier than maintaining support. Frequently you have the big kickoff announcement and then support can begin to wane.
Sure, we all want the best quality folks for our projects and want our projects to be Number 1 on the priority list; however, SPI projects truly belong there. This is one of the few projects that evolves into a program and needs constant nurturing from executive level management to survive. SPI projects will have a strategic effect on your organization, affecting areas outside of the IT domain.
Strategic Interview Sessions
In order to obtain and maintain this support, you must conduct detailed strategic interviews with all of the impacted executive management, both within and external to the IT organization. Compile the input, create a summary report and confirm both accuracy and importance of strategic business goals. If SPI work meets these goals, you have a winner. If not, you may want to reconsider launching this type of project.
Strategic Relationship Management
As noted above, maintaining the diet is the toughest part. So goes executive strategic relationship management. It is quite easy for executive level management to become distracted or disinterested.
In real estate it's, location, location, location. To maintain strategic support its, communication, communication, communication—in their face addressing their issues identified during the strategy interviews. I recommend meeting with executive management on a biweekly basis. Additionally, reassess those business and process goals every six months or so. Adjust your business case, plans, and strategic session meeting agenda items as necessary to look where executive management is looking.
Tactical
One of the more interesting and diverse groups to deal with is middle management. They can be your best friend and worse enemy. They have connections and can influence both executive management and practitioners. You need to ensure that the SPI project meets their needs.
Just as you do with executive management, conduct tactically focused interview sessions. Create your report and review it with the mid-management team for accuracy and level of priority. Help this group understand where executive management is looking and what their teams are looking for. Discover their needs and insure the SPI project addresses them clearly and distinctly.
Project Delivery Pressures vs. the SPI Initiative
Frequently, project delivery dates are considered more important than the SPI initiative. This perception is a result of poor communication, training and management understanding. Often, one of the key reasons the SPI project was started was due to missed project dates. They don't quite understand that following the process will give them a better chance of meeting this date.
The dot-com, I want it yesterday culture does not feel comfortable unless they are coding or debugging. They just don't feel productive. This will be one of the toughest areas for you to manage. Organizations below SW-CMM™ level 3 frequently feel that way. They do not have the experience that shows them how following the process will actually shorten the overall delivery time. Faith helps, but perseverance, leadership and executive level support will help you through this challenge.
Local
The folks who create, follow, and use most of the process will be your greatest supporters and most vocal about the process. It is absolutely critical that this population be involved in the creation of the overall process and the SPI project. Local practitioner personality requirements include:
- Respected in the organization
- True believers in SPI
- Cheerleaders for the SPI project and program
- Your most talented
As far as the highest priority of the above items, it can be debated. However, find the folks who have these traits. You will run into an argument on putting some of your best people on a SPI program, in light of other project delivery dates. Don't sacrifice short-term goals for long-term and strategic objectives.
Representatives from this practitioner/user group(s) should be included from the beginning. This is the initial step to obtain buy in.
Developing Support Outside Your IT Organization
SPI projects will involve folks from outside the organization. Whether they are internal or external clients, these folks will interact with the new process. It is essential that that they be involved in helping you to define the process for working with your organization. The more frequently clients work with your organization, the more involved they should be in the SPI project.
Internal client examples include: Human Resources, Procurement, Marketing, Sales, Operations and others.
External client examples include: Customers, suppliers, stockholders, venture capitalists and the government.
The Gap Analysis/Mini-Assessment
Frequently, IT organizations need to understand what they do and do not have before they start developing a new process. No matter how disorganized an organization may be, there is some process they are using. Most likely, templates, describing the hows, will exist. When these are found, they should be used in the overall SPI solution. This shows that your people's ideas are valued and supports buy in to the SPI project.
Exhibit 2.Tier Representation Diagram
A Gap Analysis is the preferred tool for this. If the organization has a business need to obtain an official SW-CMM™ assessment, then it should be conducted. A Gap Analysis is a more efficient way to determine what exists in your organization and has a shorter timeline.
Our mini-assessment teams are composed of both our consultants who lead the analysis and organizational resources. There is a brief training session, followed by a set of in-depth interviews and data consolidation tasks. A report is developed by the team, scrubbing out the “who said what” details, leaving the data for presentation.
Finally, the results are mapped to the strategic, tactical and local practitioner objectives and quantitative goals. A business case for the SPI project is created, submitted and approved. Once approved, a plan is created.
Planning
Based on the information obtained during the Initiate phase, we suggest that several different alternative plans, meeting the objective and quantitative goals are created. These plans should be reviewed with strategic and tactical management as well as the local folks.
Business objectives should be reviewed and the best plan should be chosen by the team to attain the objectives of the SPI project. It is critical that all SPI projects and programs be mapped to business goals; this ensures that the SPI project and program are beneficial to the organization and makes it much easier to maintain focus and support.
Executing
During the execution phase, you need to coordinate both people and supporting resources. We have found IT resource availability to be quite thin. It is difficult to obtain resources who can be 100% committed to this type of project.
A successful model is as follows. At least one IT resource from the IT organization needs to be 100% committed. This person needs to understand SPI and Project Management disciplines. They need to be respected by all levels of the organization and have leadership qualities. For this paper, they will be known as the SEPG lead.
One to four teams, depending on the scope of the SPI project, should be created. Teams should be no larger than 10 members, including the SEPG lead and two SPI consultants. These teams should meet twice per week, two hours at a time, facilitated by the SPI consultants and managed by the SEPG lead.
Generally, we do not recommend these team members be assigned work outside of the working sessions. There is significant need for these resources to be involved with some delivery project. This model strikes a balance, allowing the SPI initiative to continue without severely hampering the overall operation. However, the cost is a longer duration for process development. As for supporting resources: an administrative assistant should be utilized to set up meetings, manage schedules and other logistical support, allowing the SEPG lead, team members and consultants to focus on the process development.
Customization/Process Creation
During the execution phase, we have found the most efficient way to develop a process and supporting templates is to work from an existing framework and or materials. The Gap Analysis will identify many processes and templates to work from. Additionally, our SPI offering supplies several process frameworks, with templates and metrics, compliant with SW-CMM™ Level 2 or 3. These frameworks were derived from the Telcordia assessed SW-CMM™ Level 5, certified ISO 9001 and TL 9000 process.
Working from these artifacts, our SPI team will facilitate the client IT organization to customize these artifacts using their language, culture and methods. The result is a solution that meets the IT organization's business objectives, quantitative goals, obtains buy in across and vertically within the organization.
The final process can then be used and continually improved. This process is referred to as the tactical or Tier 2 (Exhibit 2) processes because it is the overall process for the organization. Local procedures will be used by sub-departments or at the project level when special processes are needed based on the type of practice or product.
Tier 1: Policies
Policies define the basic principles that will be used to guide the conduct of all development projects performed within the organization. These policies will be created and owned by the Quality Management Team (QMT).
Tier 2: Processes
Within this document, Tier 2 is referred to as the quality process. The Quality Process is an end-to-end project process framework. This layer defines the process framework used to conduct any development or support project within the organization. The process framework identifies the phases for a project and the activities and steps to be performed within each phase. Templates for artifacts that are used or produced within individual activities are provided. Project roles and responsibilities are also defined.
We recommend the following criteria should be applied to the quality process.
• The process represents an agreement between management, the SEPG, and the application teams within the organization about how projects will be conducted to ensure the successful development and delivery of products and services to customers.
• The process must be usable within different application teams and should not define activities that are used only within a single team or are customer specific.
• The process definition will not provide tutorials about how to use the process. Tutorial information will be provided elsewhere.
• The process definition is not life-cycle specific. It can be adapted for use in a Waterfall, Spiral, Incremental, Rapid Development, or other types of project life cycle.
• Recognizing that there is no one-size-fits-all process, this process identifies what must be done to conduct a project (i.e., process activities and steps), but allows individual departments or application teams to define how those process steps will be performed (local practices).
The Software Engineering Process Group (SEPG) with guidance from the Quality Management Team (QMT) and support from various informal working groups will develop the Quality Process. The SEPG will be the owner of the process.
Tier 3: Local Practices
Each department or application team within ISDS is encouraged to define local practices. A local practice defines how the department will perform a specific process step in the Quality Process. This facilitates tailoring of the process to satisfy the needs of specific departments. Note that most steps in the Quality Process do not require that a local practice be created. In addition, with approval from the SEPG, the QMT, or both the SEPG and QMT, a department may define a local activity that replaces an activity within the Tier 2 Quality Process definition. Local practices are required to conform to the Quality Process.
Overall, keep the processes thin and simple. Corporate policies should be no more than six sentences. If you do this, your chance of implementation and follow through will be significantly increased. No one wants to read through 12 inches of process documentation.
Controlling
As with any project, the SPI project needs to have its progress monitored and measured. Any variances to the plan need to be reported to the team and management along with corrective action plans.
And again, just like most other projects, the most common problem is staying on schedule. The most common cause is the inability of the process definition team to come to agreement on the contents of templates.
Since the most talented and passionate people have been chosen, it is sometimes difficult for them to agree where one item ends and the next begins. If the schedule begins to slips, these options usually work:
1. Facilitate the work sessions with greater diligence.
2. Take the folks who are passionate about the issue to a separate meeting. Lock them in a room, and do not allow them to close the meeting until they come to agreement. It is during these meetings where your facilitation and crowd control skills kick in.
3. If they still fail to come to an agreement by the deadline, the SEPG lead makes the decision and continues on.
These remedies will usually bring the teams back on schedule.
Human resource issues can rise from time to time. As mentioned above, passions can flare. It requires you to set your meetings with a strong set of enforceable ground rules. The process development, strategic and tactical teams must set their own ground rules and live by them.
Team composition is also important. When building process development teams a number of factors need to be addressed:
• All departments/organizations affected must have a representative.
• For example, when building the requirement management process, you should have representatives from your client orgs, business analysis, design, architecture, testing, and support
• Teams should be no larger than 10 people.
• Kick off sessions should be held. Focus on developing team morale. Expect to go through the storming, norming, performing stages of the team's life cycle.
Closing
Once the process has been created, the user community and all levels of management trained, and rollout started, it is important for the deliverables to be accepted, signed off and the first process improvement project brought to an official end allowing the process improvement program to begin. A formal lessons learned session should be conducted and the findings shared across the organization. These lessons will serve the eventual SPI program.
This allows the teams to recognize the formal ending of the project, but also allows the project to evolve into an overall SPI program with new SEPG and SQA teams.
P.S. Don't forget the celebration party!
SPI Project Management
This section will focus on project management within the nine knowledge areas or PMI's PMBOK® Guide.
From our experience, all of the nine (Integration, Scope, Time, Cost, Quality, Human Resource, Communication, Risk and Procurement Management) knowledge areas of the 1996 PMBOK® Guide apply for a SPI project.
The Final Draft, October 1999,“Applying the PMBOK® Guide to IS Projects” is also an excellent reference and quite helpful.
Integration Management
SPI planning usually involves the following phases: Strategic Analysis, Gap Analysis, Process Customization, Training and Implementation Support. Each of these phases has its own project plan development, execution and change control.
An overall project plan that encompasses all the phases is created along with the client. This plan contains all of the knowledge areas mentioned here. The newly formed team then creates subproject plans for each of the phases. Although all of the knowledge areas are touched on, the project plan is a thin document. Most of the effort is spent in the scope and time management knowledge areas.
Scope Management
Scope management is a challenge, just as with any other software development project. There is a tendency to increase the scope from IT process improvement to processes external to IT. Frequently the additional processes involve decision-making for a business to decide which projects should be considered before they are submitted to the IT organization.
It is my opinion that this type of scope creep is beneficial to the organization. Frequently, IT organizations are inundated with requests for projects, both small and large. Additionally, priorities switch on a daily basis. This makes it quite difficult to run the IT organization. If the overall business can control the manner in which projects are submitted to the IT organization, and the priorities can be maintained, the overall operation will run smoother.
After the scope of the SPI project is defined, all involved must verify it. This includes executive-, high-, mid- and low-level management. It is critical to explain what the SPI project will entail, the commitment from each of the people involved and the duration before each person signs off.
Once signoff is obtained, you will frequently need to proceed through a contracts management review, obtain purchase orders, non-disclosure agreements and the like. Work with your clients through this effort and plan for it.
Other than the initial scope creep of adding strategic processes to the IT SPI initiative, there is little additional scope creep. If you do experience a need to modify the scope of the SPI project, use the change control procedure you have outlined in your project plan.
Time Management
During the set up of a SPI project or program, you should create a high-level schedule. This schedule should include the gross level activities, the sequence in which they will be performed, and rough estimates of duration.
Refine the schedule to the necessary level of detail to manage a SPI project. Working with the SPI team, define what specific activities will occur during the duration of the project. If terms or phrases are unclear to other departments, clearly define what these mean. Indicate the dependencies/predecessor tasks so that each person is clear as to what needs to occur before the next task can begin. Duration estimates for process development or framework customization may be difficult if you have never attempted this before. In general, the larger the organization or team size, the greater the duration for creating each process and its supporting template(s). Once you have put this all together, you will have created your first base line schedule.
Next, develop a number of plans to use if you are unable to maintain schedule adherence. These could include the typical, add more resources, however, setting reasonable ground rules and enforcement of those rules usually works well. After you execute your schedule, track your performance. Additionally, we suggest updating the schedule weekly.
Cost Management
Following on the schedule development, you should have a fairly accurate estimate of the necessary non-human resource needs. These include: computers, printers, network links, additional hardware needs, conference rooms, servers, software, work areas, training costs and the like.
Based on your schedule, estimate the number of people hours you will need and the cost of those people. We suggest you keep this to an hourly level.
Combining the above two areas, estimate the total cost, add in the appropriate amount of management reserve, determined by your organization, and you will have your first cut at your budget.
If you organization does not allow for risk reserve, you will need to educate them. Try not to be defensive, rather educationally offensive. Bring them to your side, but expect negotiation.
As with schedule management, you will need to develop a number of plans to mitigate any cost control issues. Take the time to do this. Review it with executive management and obtain their support. Frequently, this will be an area to revisit on a monthly basis.
Quality Management
Even though SPI projects and programs are designed with quality in mind, don't fall into the trap of, “Do As I Say, Not As I Do.” It is important to develop a quality plan within your project plan.
Although you will not be conducting code inspections, you will need to ensure the quality of your process and supporting templates. Watch out for spelling errors! Maintain a central glossary for definitions and acronyms. In your SPI project role descriptions, assign specific responsibilities for process and template quality.
Also assign a process quality assurance role. This person is responsible to oversee quality compliance of your SPI project. Clear control methods must be laid out if folks do not adhere to the quality processes within the project.
Utilize a configuration management tool for version control, security, back up and maintenance of all the project artifacts. Again, the quality assurance person should oversee the operation of the configuration management system and take corrective actions when necessary.
Human Resource Management
During the development of the high-level schedule and scope, you should begin to address the available resources and their skill sets. Determine who is available. Interview the candidates for your team. Be very wary of resources who are always available or have multiple “issues”!
This is an area where your challenge will be greatest. You need folks who are leaders, respected in the organization, cheerleaders, and support the SPI initiative. If other projects are competing for these resources, you will need to justify keeping them by mapping the strategic business needs to the SPI project and then to the resources.
We also recommend the use of an outside group to facilitate the SPI process teams. It can be difficult for co-workers to facilitate themselves. Frequently, the co-worker relationships are too close and you will need the independent facilitator to keep the group focused, lower the emotions and enforce the team ground rules.
We have found that team kickoffs and small celebrations are crucial to a team that is developing and experiencing the forming, storming, norming phases of team life cycles. Teams are delicate and need to be nurtured. Many of the team members have a different focus and culture. They now have to work together and come to agreement on the corporation's processes.
Communication Management
As with all projects, the most common item to appear at the top of a project priority chart is communications. This is also true with a SPI project and program. If folks, at all levels, don't know what is happening, interest will be lost and the project will die.
Plan to communicate! Identify who needs to know what, when and in what format. Put these tasks into your schedule. Develop contact information tables of all team member information including: office phone, cell phone, pager, email, etc. Plan for coverage communication in the event of sickness, vacation, and emergencies.
Risk Management
Risk management is not to be taken lightly. I have mentioned a number of possible risks throughout this paper. Add to these the risks that are inherent in your organization: Has a SPI project ever been tried before and failed? Do you have a large turnover of management or practitioners? Does your mission frequently change?
Note: Risk reserve is more applicable to fixed-price contracts or time and materials projects with a cap. I may be used in pure time and materials projects, but that is an exception.
All of these should be addressed and identified. Now what do we do with all of this information? Many papers have been written on ways to quantify, handle and manage risks. From my experience I suggest you develop a basic table to:
• Identify the risk
• Determine the risk probability (what the percent chance that this risk will occur)
• Determine the cost of the risk (if the risk does occur, how much money will it take to fix and what affect will it have on the project schedule)
• Quantify the risk (multiply the risk probability by the cost)
• Set aside some risk reserve for each risk
• Develop a risk response plan for each risk. For risks with high quantifiable numbers, I suggest you develop multiple plans.
Update the risk plan weekly. When a risk ceases to exist, take that risk reserve and add it to the profit and loss statement of your project. Don't give it away; you may need it for a future, yet unknown risk.
Procurement Management
As mentioned in the Human Resources Management section, I suggested using an outside consulting firm to help guide your SPI project and program. This in itself involves a need for procurement management.
Develop a plan and criteria to solicit, select and administer all outside parties. Although a contracts procurement or management group frequently handles this, you need to work closely with them to ensure you are getting what you need and that the language is clear for the consulting team that will help you.
The SW-CMM™ v1.1 has a key process area called Subcontract Management. I strongly suggest you review this when developing, executing, controlling and closing your contract. Review this contract on an as needed basis to stay current and knowledgeable. This will assist you in controlling your SPI project.
When ending the SPI project, be very clear that the project and contract have come to a close. You may desire to modify the scope of the contract. Refer to the scope change control process.
Knowledge Area Summary
Over my years as a project manager of software system development and implementation, software development projects and construction projects, I saw no difference in the importance, priority or application of these nine areas. All remain critical to a well-executed SPI project. And, they continue to remain critical as the project evolves into a full-fledged program.
SPI versus SDP (Software Process Improvement Projects versus Software Development Projects)
As any project goes, SPI is similar to many projects in several areas:
• Need to capture and maintain senior management sponsorship
• Need to maintain focus across affected groups
• Need to have a budget, project plan
• Need scope control, but with a bit of a twist.
Similarities
Senior IT Management Sponsorship
This is covered in the Initiate phase above.
SPI sponsorship must come from the highest level within the department. For Telcordia Technologies, our COO was the sponsor and followed up on a monthly basis. For those who chose not to support it, they were let go, including executive-level management personnel!
Where our focus on keeping executive-level management frequently informed waned, the project also struggled. Where we kept consistent communication with executive-level management alive, the projects went much smoother. The area most impacted by this difference was in project priority and assignment of personnel.
Project Priority
Like any project, we would all like to see our project as Number 1 in priority. But in the land of reality, products must be produced and support must continue. These other items will compete for resources. Multi-tasking on development projects is usually a bad move. The amount of time it takes for a person to switch from one development project to another can be significant, reduces overall productivity and increases the number of coding errors.
SPI Projects should be Number 2 or Number 3 in priority for both the IT department and other cross-functional departments; behind production support only. Competition for “top” resources will always be a problem, however, the investment made in SPI by those who are respected in the organization will pay off in the long run. Do not settle for “bodies.” Your team must be composed of respected personnel who can also be cheerleaders and coaches for the project. Further detail on this issue is covered in a previous section.
Focus Across Groups
When developing a software solution, IT must be involved with the client across a number of areas: Human Resources, Finance, Operations, IT, various Subject Matter Experts, etc. This is also very similar but also different. The cross-functional teams involved in SPI come from within the affected organization(s).
Project Plan With Associated Budget
Again, all projects must have a Project Plan, not just a project schedule. The plan must have an associated budget. I hate to use the cliché, but “Fail to plan, plan to fail!”
Scope Control With a Twist
Again, as with any project, a scope must be established. We recommend the ability to easily modify the scope of the project. Since most clients are SW-CMM™ Level 1, their ability to clearly define what they want is difficult. After several weeks, we can better ascertain what the client really wants and modify the scope through the agreed upon change control process. So basically we plan and expect the scope to change.
The most frequent scope expansion involves a move into strategic planning, program management office and cross-organizational issues.
Differences
SPI projects differ in the following areas:
• SPI projects will involve more than just the IT organization
• SPI projects become part of the corporate culture
• SPI projects evolve into a continuous improvement program within the overall quality initiative
• Formal Software Process Improvement Groups are created from members across the organization, not just IT
• Push back on Process
• Continuous Management Support.
The Whole Organization
Senior and executive management support must be from all departments across the corporation. SPI is not just an IT issue. SPI involves culture, language, and process change to Human Resources, Finance, Operations, Sales, Marketing, and other areas. So executive management from all aspects of the corporation must be involved and supportive of the SPI plan. This is a change in thinking and may necessitate conversations at the CEO level, depending on the corporation size.
Where our SPI projects tend to differ, are the areas we focus on for levels of management.
Executive management is responsible for developing, instituting, and supporting corporate-level policies (one or two paragraphs). Middle management is responsible for reviewing, editing, and approving the software development process: activities, criteria, steps, and templates. Lower-level management is responsible for the development of local practices.
And then there is the Software Engineering Process Group (SEPG). This team is composed of different levels of management and engineers. Working together, they help develop, control, and modify the software development process. They also become the cheerleaders and coaches.
Since the new development process will involve all aspects of the organization, it is imperative that representation exists from each department. I cannot emphasize this enough; the representatives must be respected in their discipline, believe in the new process, support it through coaching activities.
Volatility is also one of the most challenging areas to deal with. Level 1 organizations usually suffer a large and frequent turnover in both engineer and management ranks. The volatility can ensure any project failure. However, we have seen that SEPG and SPI team members tend to stick it out unless reassigned by management. They realize that this project will help the overall corporation be a success. The team members actually challenge management when a group member is to be removed.
Corporate Culture
SPI is culture change. The project team, SEPG and organization will develop and use a consistent language. That in itself is a large jump. Frequently, different suborganizations use different words to describe the same thing or vice versa. The SPI project will develop one glossary to be used, not only in the IT organization, but also across the company.
Responsibilities will be formalized and tied in with roles. No matter what project team you go to, each person's role and responsibility will match. Everyone knows what to expect from whom and at what level of completeness.
Teamwork, especially cross-functional teams, are much more critical in a SPI project. The level of anxiety, passion and emotion will be much higher. Why? Because this project is going to guide the way you work from now on. Each person and department has its own set of values, priorities and needs. Each will bring their passion to the table. You will need a strong facilitator to guide and manage this truly cross-functional team. However painful it might get, the payoff will be worth it!
Some areas to be aware of:
• Some people will tend to control or be heard over the rest of the group. This cannot happen.
• If you see someone give up, stop the discussion and pull the person back in. This needs to be a cooperative engagement.
• Set the ground rules, impose fines (suggestion of $1 per incident) and enforce them.
Evolving Into a Program and Continuous Improvement
One of the other unique things about a SPI project is its inevitable evolution into a program. Software Process Improvement, by definition, is a continuous program.
You will not get it all correct the first time. Users who were not directly involved in the process development will have suggestions for improvement. SPI project team members will realize better ways when they begin to use the process. And, your business will change affecting the process. All of these items will affect your process.
Many times businesses feel, “Well we did it, now go and follow the process forever.” NOT! This will lead to process failure and a depressed group of employees. Your process will need tender loving care, constant attention and monitoring for compliance via the Software Quality Assurance team (not testing, rather process compliance).
When you see the commitment to evolve from a project to a program, your chances of improving your business, reducing cost, increasing quality and customer satisfaction are greatly enhanced.
The SEPG
One of the unique features of this program is the formation of an SEPG. This team is responsible for the maintenance, control and constant improvement of the process. They are also responsible for ensuring that all local practices meet the Tier 2 processes.
Although an SEPG is a SW-CMM™ Level 3 issue, we recommend forming the SEPG while working toward Level 2.
The SEI recommends a SEPG that is 4–8% of your development population. Example: An IT organization with 100 developers should have an SEPG of four to eight people full time. Anything less shows poor commitment and has a high probability of failure. As your organization matures and achieves higher levels, the percentage representation drops. In fact, as of the writing of this paper, Telcordia has 4800+ developers and the SEPG is 33 people. Keep in mind that we have been Level 5 for two years now.
Exhibit 3
Creation
The SEPG should be created from several members of the original SPI project team. Again, we stress the importance of quality and respected people. Without the proper resources, your SEPG will not be respected; hence the process will fade away very quickly. The SEPG leader must manage and promote with tenacity. They must be committed to the philosophy of process but not religions zealots and have the very obvious support of senior management.
Transition
Clients have opted to rotate one SEPG member every quarter. Although this is a concern, we do not have any data that indicates if this works or not. However other studies do support this practice with a well-developed transition plan.
Process Pushback
This is a continual area of concern and unique to the SPI project and program. You will experience pushback from all levels of the IT organization and across the business. Many folks, who perceive that the new process will just slow things up, will need to be educated. For whatever reasons, they still believe that the old chaotic way is still the best.
The best defense is an offense. If strategic/senior management, across all departments, shows actual support for the new process you will have a success. And the success chain will only be as strong as its weakest link.
If strategic support is hard to come by, interview the folks who are challenging you. Dig down and find out the underlying reasons and address each one on its own merits.
Unique Challenges
Because a program has a longer duration than any project, it will be a greater challenge to maintain both interest and commitment. Until the process is completely socialized in the organization, the challenge to commitment will remain. Refer to the previous section.
Middle Management Sponsorship
Middle management can be a strange animal in SPI projects and programs. On the outside, they support the initiative. However, they will tend to undermine it. Through various conversations at different client sites, the most common reason behind this behavior: The process is a perceived challenge to their level of control. They feel threatened.
This group of people must be directly involved in the creation, review and iteration cycles of the process. If middle managers feel threatened, they will micromanage projects that follow the process and in the worst cases become a subversive middle management team. Tread lightly but firmly. Above all, pull them into the SPI team atmosphere.
Conclusion
Software process improvement projects are much more strategic than software development projects.Value perception will require constant maintenance.
You should have a better understanding of how to better initiate, plan, execute, control, and close SPI projects and the specific issues that arise. SPI projects and programs have a unique set of critical issues that must be focused on for the success of a SPI initiative.
The SPI project is just the start of a number of SPI projects in the journey of SPI programs. SPI is a journey, not a destination!