Risks Involved for a High Maturity Organization to work with a Low Maturity Organization

Abstract: 

This paper highlights some of the practical scenarios encountered in having to deal with differing process maturity in interplay. Requirements originated from the lower maturity organization and were often either dictated by the marketing department or were not very stable. Requirements management within the context of the lower maturity organization was always non existent. It was left to the higher maturity organization to document such changes and accordingly set the implementation goals. In such a scenario, the following appears to be the risks involved.

Index Terms:

Capability Maturity Model, Configuration Management, Cost Performance Index, Process, Requirements Management.

INTRODUCTION

For a high maturity organization to conduct business with a lower maturity organization, the risks involved are enormous. The image of the high maturity organization will be the first at risk for being damaged. Apart from the standards getting diluted in order to accommodate the requirements of the lower maturity organization, quality of the end product will suffer immensely due to time constraints within which the product will have to be developed while accommodating the process overheads.  In the paper Software Process Improvement at Hughes Aircraft [1], Humphrey, Snyder and Willis discuss that productivity and quality increase with reduced risk levels as the maturity level increases from 1 to 5.  This assessment however, is highly dependent upon the maturity of clients with whom the organization will interact.  Given the fact that, of the 284 assessments performed in 1994, 75% of the assessments indicate level 1 capability, 16% of the assessments indicate level 2 capability and about 8% of the assessments indicate level 3 capability, a good 99% of the assessed software industry is below level 3 maturity [2].  This situation has not changed drastically at the time of this writing in 1999. Even though organizational processes have matured, the operational processes addressing the business needs of an organization are most definitely at a lower maturity because of the scenarios identified in this paper. Process management and adherence to it in this context is not only a matter of a tremendous overhead for a high maturity company but may also be a tremendous risk when it comes to relating its processes with other lower maturity processes.  A few scenarios are discussed in what follows.

SCENARIO 1 

Changing requirements from the lower maturity organization.

Unstable requirements and frequent changes to requirements without a modified delivery schedule is a very common feature.  Even if this means a lot of extra work for the higher maturity organization to cope up with, such as, modifying the end of phase deliverables from all the phases and then having to modify the code, it might not meet the schedule deadlines.  This is especially so, if the lower maturity organization cannot make up its mind on whether the change is required or can be postponed for a future release.  Most of this uncertainty is due to the fact that requirements originate from the marketing department that has to face a very competitive end user market.  The concept in such a work environment is “if the technology or the software is late, it need not be there in the first place”.  What is often targeted for is the look and feel of the software in order to gain a market penetration.  So, a quick and dirty prototype is developed to fulfill this goal and then software is built using this prototype as reference.  In a mature software development organization where the emphasis is on end of phase deliverables and making sure that reviews and previews are effectively conducted, a software development effort involving a quick and dirty prototype is a potential challenge and a big risk.  Though prototype code is considered to be a throwaway code, if the prototype is received well by the customer, it becomes the basis for further development. 

This risk is further compounded if the lower maturity organization does not keep track of all the changes to requirements it requested.  This situation can be alleviated to an extent by the higher maturity organization by periodically updating the lower maturity organization of its changes to the requirements.  This is a major overhead for the higher maturity organization because it will have to dedicate personnel to monitor the changes and keep the customer appraised about them.  Firstly, it is difficult to find software specialists or software configuration managers who are willing to do such a job and secondly, it requires a software specialist to make these changes to the requirements because the end of phase deliverables from the analysis and design phases require such skills.  So, this is the second risk for such projects.

This situation can go out of control, if the customer is geographically separated and does not acknowledge changes to requirements in a timely fashion.  In spite of having a common development environment and configuration control mechanism, the situation is bound to deteriorate over time.  This is because code development will require the discipline to communicate changes on a daily basis for both teams to synchronize.  This might mean that code releases to either side happens on a daily basis.  Finding the resources to do it effectively is a third risk.  Some of the resources, which are likely to be unavailable on a consistently reliable basis, are -

• Updated and debugged software at the end of the day.

• A mature configuration manager and systems engineer on both sides who will coordinate the teams activity without letting frustration to creep in.

• Teams that believe in a win-win spirit of cooperation.

•  Stability of teams on both sides.

• Internet access from both sides in order to perform telnet and ftp.

• Configuration management system that is well understood by both the teams to be able to manage the software development. 

With so many changes happening to the hardware and software platforms and vendor support for operating systems changing, there is an organization need to move to newer environments calling for a tremendous amount of latent learning curves.  To cite an example, Domain Software Engineering Environment (DSEE) is a configuration management system in the Domain Operating System.  With a change in focus of the software industry from this OS, a new configuration management system will have to be instituted which comes with a lot of added learning and idiosyncrasies that requires time to understand.

SCENARIO 2           

Inheriting legacy systems from the lower maturity organization for feature updates and for future maintenance.

This is by far the most serious by way of “degree of risk”.  Such legacy systems may not have a great deal of documentation to support the process that was adopted to develop the code.  It requires highly skilled software specialists from the higher maturity organization to read the code and understand what is going on.  Often, such an understanding comes after a lot of time is expended.  For the higher maturity organization to get an understanding of how the feature changes will be handled, it must first do an impact analysis [3].  This requires a schedule to be determined after an assessment of the existing legacy system.  The legacy system may have the following risks.

1.       No configuration management.

2.       No documentation except code.

3.       Code that is cryptic and is not governed by any coding standards.

4.       Feature enhancements are to be based on software tools that have not stood the test of time.

In such a situation, the onus and the consequent risks on the higher maturity organization are tremendous.  The amount of time expended for creating the deliverables, which will help to design the enhancements, may be a challenge.  If the design of the older legacy system is arbitrary and defective with a guiding principle quite different from the best solution, then the feature enhancements to the software will also be handicapped.  This is a risk that will have to be accepted if the legacy system has to be reused.

As for point 4, technology transfer and tool induction is very poor in lower maturity organizations.  Tools are introduced and experimented on live projects based on no evaluation but purely on individual opinion.  Further, these decisions may become binding on the higher maturity organization to use on the feature enhancements.  If tool evaluation is not on the higher maturity organization’s project schedule, it could become a major risk for schedule slippage and associated costs.  Usually, the capabilities of the tool are superficially understood when they are recommended and this could be a major risk.  In depth understanding of the tool comes with experience with the tool and not by merely experimenting.  With a lack of tool evaluation capabilities and its subsequent induction into the organization, a lower maturity organization often passes the buck to the higher maturity organization to determine its applicability.  This is cause for a major software risk if the higher maturity organization does not have the resources at the moment or is pre-occupied with meeting customer expectations for valid business reasons.

SCENARIO 3             

Incomplete requirements specification due to an uncertain customer.

No project has begun in the author’s experience wherein the requirements were all specified which could be said to be correct, complete and consistent.  So, to expect a software solution that would have the above three characteristics besides being testable, verified and validated is a major target for being prone to risk.  If the cause-effect analysis has to be conducted by the higher maturity organization to determine whether the incompleteness of the requirement can be resolved; given the limited resources at the hands of the higher maturity organization, it could soon turn into a major technical risk.  Often the risk abatement procedure is to ask the customer for a solution, which could get into a loop.  Management wisdom and technical expertise is always at a premium and is seldom available when needed.  If this situation has to be mended, a separate group within the two organizations must evolve alternative solutions in a proactive manner.  If the resources to commit to such an activity are not available, then this lack of resources could be a major risk.

The seriousness of this risk can be mellowed to an extent by having a domain expert or a systems engineer who will be the sole customer point of contact.  The domain expert from the higher maturity organization must identify a counterpart in the lower maturity organization and resolve ambiguities and incomplete requirements.  When about 75% of these requirements are stable, it is then appropriate to begin with the analysis.  Partitioning the unstable requirements and the stable requirements is a very important first step toward managing the system requirements.  To cite an example, the user interface code in the windowing environment can be developed independent of the application code if the user interface specifications are unclear.  It is then, only a matter of designing the application code “interfaces” with the user interface code.  Testing these two independently before integrating them has the potential advantage of increasing the quality of the software.

SCENARIO 4          

Customer who cares less for the process but is interested only in the final product.

The customer is often interested only in his product.  The customer cares less as to what process the higher maturity organization is going to adopt as long as it meets the schedules and customer expectations of the software product.  In such a situation, involving the customer in the reviews and previews of the end of phase deliverables is a potential problem that could grow to become a risk if differences of opinion begin to surface in the coding phase.  There is very little time left to amend the solution and trace these changes back to the end of phase deliverables of the prior phases.  This situation can soon turn into a chaotic situation.

While adherence to the process may be a matter of prime importance to the higher maturity organization, it must not overlook the importance of creating defect free software.  If a mature software production process cannot ensure defect free software with deliverables on schedule, then it is like saying, “the operation was successful, but the patient died”.  Micro management of the process and the product development effort by the management is a very useful step to reduce the magnitude of the risk.

SCENARIO 5

Customer who believes that a process is applicable only in a stable environment such as an automobile or a chemical industry but is seldom applicable to software.

It is not very difficult to relate to this scenario!  The common feeling is that software soon becomes a legacy system, whether inherited or created by an organization.  And the analogous reasoning, which gets a good amount of consideration, is, “if the input to an automobile manufacturing process is a totally beaten up machine, then the tinkered product is going to be as defective as defective software”.  Giving this reasoning some thought, it is quite obvious that, the creation of software processes just because an automobile manufacturing industry or a chemical industry has a process, may not be appropriate.  A process in the context of software is to bring or apply a few controls in an otherwise chaotic situation.  But, the challenges and the risks are an unavoidable outcome of the very nature of software development activity, it being a creative science goaded to action by the principle of - “to create a technology which is new and ahead of its time and every one else”.  This is further complicated by the lack of experienced software testing capability in the industry.  Though testing is a recognized activity even in a level 2 process, there is a lack of effective CASE support in this area.

Value addition from the use of a process comes about only if there is an effort toward automating the transitions across the more formal phases of the software development life cycle [4].  If the use of a process model does not reduce cycle time and improve quality, then there must be an effort in evaluating the process transitions with a view to automate as many of these transitions as possible [5].  To cite an example, “code standardization” is a very formal transition after implementation.  This transition can be easily automated in order to improve the virtues of the baseline code.  It introduces uniformity of appearance to the baseline code with consistency and a reported cycle time reduction of about 1303X [6].

CONCLUSIONS

The trivial solution available for a high maturity organization when faced with the scenarios discussed in this paper, is to not do business with lower maturity organization.  This is seldom the best choice considering the very high percentage of the assessed software projects to be at levels 1 and 2 on the CMM.  There are also valid business reasons to work on projects from highly time critical, market driven software projects of a low maturity organization.  Most market driven software development activities will require the organization to make intelligent initial guesses and informed decisions in the face of uncertainty.  If the initial guesses are quite different from what is expected, it will also require a lot of rework.  The cost to rework in such a situation cannot be computed before hand and often the cost-performance index that is defined as the ratio of budgeted cost of work performed to the actual cost of work performed is far from the ideal measure of 1. 

To summarize, even if the assessed capability is at a level 5 maturity on the CMM, given the fabric of the current maturity levels in the software industry, a level 5 organizations will have operational processes much below a level 5 because of its interactions with lower process maturity levels.  The major risk for the higher maturity organization is to stake its image and its processes in order to stay in business.

However, organizations that reach higher mature levels have a very important responsibility to perform.  After reaching say a maturity of level 5 (Optimizing) on the CMM, software automation along with reuse and external process education should become a very important organization focus. Hence, these may need to be added as KPAs to the existing Defect Prevention, Process Change Management and Technology Change Management Key Process Areas at Level 5.

The paper discusses first hand experience of the author with projects having the characteristics described in the various scenarios.  The author has intentionally concealed the project details to maintain confidentiality and proprietary nature of the information and to focus only on the real issues that can be categorized as risks.

REFERENCES

[1] Watts S. Humphrey, Terry R. Snyder and Ronald R. Willis, “Software Process Improvement at Hughes Aircraft”. IEEE Software July 1991.

[2] Herbsleb, J., et al., “Results of software process improvement efforts : Work in progress.”, Proceedings of the 1994 SEPG National Meeting.  Pittsburgh : Software Engineering Institute, Carnegie Mellon University.  1994

[3]  R.S. Nandyal, “An Approach to Rework Projects”, Software Engineering Symposium, Motorola.  Phoenix, Arizona.  1993.

[4]  R.S. Nandyal, “Cycle Time Reduction:A Survey of Solutions”, Software Engineering Symposium, Motorola, Chicago, Illinois.  1994.

[5]  R.S. Nandyal, “Automation of the product Life Cycle - A Solution to Cycle Time Reduction”, Software Engineering Symposium, Motorola, Chicago, Illinois.  1994.

[6]  R.S. Nandyal, “Integrated Software Engineering Tool:ISET, Process Automation Software”, Motorola Tools Fair, Software Engineering Symposium, Motorola, Chicago, Illinois.  1994.

BIOGRAPHY

Raghav S. Nandyal is a General Manager heading Methods, Tools and Products Division for Intelligroup Asia Pvt. Ltd.