Process Rich vs. Just enough: Is “Just Enough” Enough

 The beauty of process is not just about its richness, but about its effectiveness and agility to ensure high performance.

It might be time for CIOs to look at  “Just enough” concept. “Just in time or Just enough processes and controls to deliver a quality product / service; to get the developers and service providers closer to the end users while lowering development and delivery cost. For example, in some organizations, there are software development programs where the cost of code development is less than 30% of the cost of the program, and the program management functions are over 25% of the cost of the program. Alternatively, in another project, where the risk process with risk controls and risk control boards takes more staffing than the coding process.

Is “Just Enough” enough? It could be situation-driven and context-dependent, but IT leaders can spend some time to walk through following key highlight:

• Do you understand “letter of law” or the “the spirit of law”:  For all project management to be successful, all stakeholders need know the goals, objectives and the reasons for process and procedures. They have to be able to add reason, and common sense to the procedures. Process and procedures must be saleable so delivery, product, or service remains the primary focus. Too many cases that people blindly follow procedures without knowing the reason for the procedures; they know the “letter of the law but not the spirit of the law” 

• Is “Lean” still too Rich: Some firms have attempted to address this problem with a “lean” process, even the lean process is in itself too process rich. It is a commonly held belief that the better application of process leads to better quality results, and this is certainly true of the manufacturing process, where failures are often measured as x failures out of a million. However, it is a mistaken belief that software development can be modeled accurately by the manufacturing process. Development always requires the application of both science and art (or creativity), and consequently the alignment of predictable outcomes with process compliance breaks down at the point that the code development requires innovative or creative thinking to solve the problem at hand. Applying the notion of Just Enough, allows one to take advantage of the experience of the manufacturing industries, while leaving one with the discretion of applying experience to the unique challenge that is in software development. 

• The main challenge is that “just enough” requires serious thinking, knowledge and skills. “Just enough” is great for those who have organizational and individual knowledge to implement it, because “just enough” is context-dependent and it has to be created and discovered. It will depend on many factors, such as culture, position of IT department, knowledge, skills, complexity, etc. Just enough is good but the problem is defining boundary of just enough and sticking to that. There is enough literature and case studies on the “just enough” approach and reusability. However, sales pitches for process paradigm and “best practices” (ITIL, PMBOK, CMM etc. ) are hard to beat in corporate environments. Many people do not want, or simply cannot, go that way. Instead, they prefer mechanical process thinking which worked wonders during the industrial revolution from the 18th to the 19th century. The process paradigm works well for industries whose production cycles are repetitive, that is; they have a set of specifications and produce certain number of products according to those specifications. Finally, the process paradigm enabled automation of mechanical production lines.      
      
• SW development is not repetitive. Specifications for each and every cycle are different. For example, every new release has its own specifications (requirements, architecture, design). Creation of SW development artifacts (requirements, architecture, design, code., etc) should drive the cycle and the process should be chosen accordingly. "Just Enough" philosophically means how to do things at simple way (Simplicity is the premium complexity), methodologically Agile is emerging as the software application project methodology because it enables the iterative user interaction, frequent team communication, and more adaptive at today's rapidly changing business environment.  

Process is means to the end, not the end, always keep business goals in mind; the beauty of process is not just about its richness, but about its effectiveness and agility to ensure high performance project delivery.

Posted in: Business Process Management,Project Management