• Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 24 other followers

  • Archives

  • Advertisements

Trust builds in compliance

False positives in compliance

Clear articulation of compliance requirements and benefits need to be articulated  to development and non technical teams. This will result in dual benefit of compliance with less documentation. It can be ISO, CMMI or any regulation for that matter. Best still is to automate the compliance requirements by inbuilt pointers into Definition of done / checklists for the development and technical teams. If the project management tool can capture the compliance or otherwise aspect much better. Some thing like Audit trails can be run to find out compliance percentage.

If the teams understand compliance requirements clearly, they might even come out with innovative ways of building in compliance during complete SDLC stage. Trusting teams will go a long way in making compliance cost-effective

Advertisements

Root Cause Analysis of complex factors

Root Causes are important for eliminating the defects by origin. Symptoms removal just works as fix.  Automated tools across SDLC helps to a certain extent on the technical aspect of Root causes with respect to syntax, structure etc. To find the logical and algorithmic errors thinking tools are required. It can be basic brainstorming to Thinking tools at the other end.

Factors like schedule pressure, skill gap, incomplete requirement, culture that doesn’t allow seeking help can be major factors in producing errors. Gold plating of requirements, over processing can also be the root causes.

Automate the syntax and brainstorm the people / culture fcators. This will help unearth root causes early in the product life cycle

Scope gold plating is risky

Correct Approximation Vs costly accuracy.

Particularly in Agile development, the first release consisting of few sprints might want to ensure minimum viable product version is completely functional and helps the users with their requirements. It is better to package the MVP (minimum viable product) and encourage users on the existing functionalities usage and obtain feedback. Next upgraded release can accommodate the short fall if any of the previous version. This is much better than trying to build all the requirements and not quite able to test the optimum coverage of the scenarios. Tailoring scope to right size is approximation here. Trying to gold plate scope too much than necessary will not only make the product dysfunctional but also will create a lasting disappointment in the minds of users.

Let us use approximation correctly and not do gold plating of scope to ensure smooth launch of product versions.

Certification initiative should be a all round thought process

What drives your certification initiative? Customer or Management or Statutory regulations or belief system in any certification standard?

Not very difficult question to answer. Mostly key stakeholders like customers , regulatory bodies, domain compliance determine the decisions.

At the deeper level when we say customer decides, we need to ponder over existing customers, prospects, pipe-line proposals all together.  Product / industry domain also are also factored while companies decide to go for certification. In auto industries most of the OEMS and auto component manufacturers ask their suppliers to comply with IATF 16949:2016, manufacturing and services companies insisting on ISO 9001, 27001 and CMMI compliance from their vendors.

While there are so much practice knowledge and experience that have gone into the making of these standards, it will be great if all the stakeholders like customers, organization and suppliers, third parties come together and take a decision about the right standard to adapt by all of them at appropriate time. This will prove effective business in the complete supply chain.

Manage Risks and leverage opportunities

Risk Management and opportunity nourishment should be simultaneously developed for high performance of product engineering teams, product management team and all teams for that matter.

Basic set of policies and procedures that are just enough will serve as the platform for people to start scaling up. If people do not follow the basic just enough policies and procedures, then it will consume their productive time for innovation and scaling up. Hence adapt to the basic stuff to set free the time available for innovation.

Use automation tools wherever possible right from Business Analysis, requirements, design, coding, integration, testing, build and release phases. Once the standard processes are complied it becomes easy for the scaling up and innovation to happen. Only thing is basic platform process should be capable of scaling to future enhancements of product development.

Risk Management provisions for cost, schedule, data (information security) and time should be carefully managed at the level of both standard compliance and innovation frameworks. Wherever possible experimenting with opportunities using high-end concepts like SAFe, LeSS, TOC and Lean can be applied in limited context. Based on the outcome and lessons learned, it can be globalized to organization level.

Right process approach is a win-win

Some of the Key reasons process implementation fails :

  1. Nil or scanty support from senior management: Senior management is busy investing time effort and money on sales, production and delivery. Production covers complete engineering aspects while delivery taking care of testing, releases and support aspects. Sales is pre sales + Engagement and customer satisfaction. Where does process fit in this premise?  ISO certification, CMMI adoption or any other domain specific certification aspects like PCI DSS or SOX or HIPAA or any other?  Even if it’s the case of certification, it is looked at by senior management as one time exercise where it can provide budget for cost and effort. Subsequent periodical assessment becomes less expensive and kind of integrated, is what the senior management thinks, for the right reason indeed.
  2. Business Process Excellent / Quality Assurance focuses too much on checklists and audit exercises pertaining to the standards and models rather than demonstrating the real ROI of adapting any model.
  3. Process is not aligned with Customer’s requirements and making it too much          towards complying with strict procedures and workflows.
  4. Good case studies / process assets are not captured articulating the values of process initiatives
  5. Lack of motivation for adapting process models. No rewards for good process        performance
  6. Once certified the system doesn’t look beyond for upgrades or scaling up.

These are some of my thoughts. What is your view / experience?

Checklists – use them prudently

Checklist uses and misuses.

Checklists have been in use for many years in manufacturing and IT industries. In IT typically development, testing and review activities have been using  checklists for complying to both process and technical requirements. In Manufacturing industries checklists are widely used for all operations in shop floor. It has helped the operational staff to ensure adherence to customer specifications, process standards and legal requirements.

However checklists should be used with right purpose and not as ticklists. Some times for audit compliances check lists are used and evidenced for audit purposes. This will reduce any innovation and improvements.

Use checklists prudently and go beyond checklist for innovation. After innovation review checklists and update for continuous processes. This way checklists will be effective and fully used.