Consulting Basics for Software Quality Contractors

Contractors and consultants serve the organization in very different ways.

Contracting is often like a regular employment relationship, except for increased independence in certain aspects of the role. For example, a contractor may be more isolated from the organizational hierarchy, which allows them greater mobility and collaboration opportunities between the organizational layers. For better or worse, contractors often have different incentive structures that guide their attitude and contributions towards a project. That may mean that the same person would likely act differently as a contractor and as an employee with a substantial equity stake in the company. Nonetheless, like regular employees, contractors are brought on for their ability to accomplish the task at hand and directly contribute to projects.

Consultants provide insight, guidance, and recommendations for a problem system. In a broader sense, consulting can be explained as providing advice for someone with a decision to make. The consulting process can be broadly broken down into five phases.

  1. Contracting

    • Establishing a mutual understanding of the consulting environment, rules of engagement, and general expectations.
    • For software quality consultants, example work in this phase includes establishing a list of stakeholders and stakeholder roles, agreeing on the extent of consultant data access, and gaining an understanding of product release requirements.
  2. Discovery and Data Collection

    • Gathering information relevant to the problem system.
    • For software quality consultants, there may be a bias towards the quantifiable, such as defect leakage, defect density, and other software quality KPIs. However, the qualitative can be just as important, such as gathering information on the client’s perspective on the problem system and the team’s attitudes towards automated software testing. The goal here is shared understanding and a plurality of perspectives on the problem system - redefining, reframing, and synthesizing information is just as important as the initial collection.
  3. Feedback and Decision to Act

    • Reducing and simplifying the problem system to enable meaningful action and analysis.
    • For software quality consultants, key tasks in this phase include identifying a refined vision of the problem system, the KPIs for system transformation, and areas with high leverage for system intervention.
  4. Engagement and Implementation

    • Creating an actionable plan that the client is motivated and able to implement.
    • For software quality consultants, this phase might involve facilitation of detailed system design and providing justification for the implementation work. At the end of this phase, the client should be equipped with the motivation, information, and guidance to successfully carry out the implementation component of a systems transformation project.
  5. Extension or Exit

    • Deciding whether to extend or exit the consulting arrangement.
    • For software quality consultants, the decision to extend or exit the consulting arrangement will often depend on the results of the consulting engagement and any new, emergent problem systems. For example, perhaps the consultant has addressed the initial problem and set the groundwork for a successful systems transformation, but realization of broader organizational objectives requires another round of consulting. In this case, it may benefit both parties to negotiate a new contract and initiate the first phase of consulting.

When guiding the consulting engagement using these consulting phases, it is easier to start the engagement on a strong foundation, avoid scope creep, avoid getting immersed in implementation, and conclude the engagement at the right time. Key throughout all the consulting phases, and the consultant’s job in general, is to avoid becoming responsible or wrapped up in the implementation. Much of the value in a consulting arrangement is the isolation of the consultant from the details of the implementation. This enables the consultant to focus on the important high level details, true nature of the problem, and system context. The consultant should provide a foundation for a successful implementation effort, not the manpower.

Clients can be disengaged and resistant to perfectly sound recommendations for a variety of reasons. For instance, software engineers can develop strong inclinations towards particular technologies, software stacks, and systems. The consultant needs to be aware of their own bias and the client’s, then work on developing holistic and objective perspectives on problem systems. If an unbiased perspective on the problem lends itself to a particular approach/technology which does not sit well with the client, some combination of education, collaboration, and reframing may improve the situation. In reality, technical concerns are rarely the root cause of client resistance, if the consultant is truly an expert in the area. Rather, interpersonal or emotional objections can often come to the surface as unfounded technical concerns. By using clear, focused, and simple language during client communication, emotional objections can often be minimized. Furthermore, situations that may lead to putting the client on the defensive should be carefully avoided. The consultant should be transparent, suspend judgment, and be careful about assumptions.

Software quality is a touchy subject because it is inherently a critique of software development work. This can be the root of a lot of resistance in software quality initiatives. On the surface level, developers may be resistant because these initiatives reveal more defects in the code that they worked really hard on. Further, software quality systems put constraints on development and can make the developer feel less autonomous and less in control of their work. Automated testing systems can bring a host of additional concerns to the team - and the quality assurance department in particular. If the organization develops automated testing systems, will the manual software testers be out of a job? Communication, collaboration, and education can remedy these concerns for many stakeholders on the client team. While the organization’s success and an employee’s success are closely tied together, it can be difficult for employees to adopt the organization’s perspective and put aside their personal concerns. The best technical solution will fail if part of the client’s team is working against you - stakeholder management, a holistic approach, and careful communication are particularly important when dealing with touchy projects.