Revitalize Your Business

Our consulting services are designed to help you revitalize your business strategy, your execution effectiveness and to capitalize on emerging opportunities, whether they are market or technology driven. We also provide services enabling you to tune your organization through structure, process and behavioral changes. The objective is to accelerate your business by improving strategy, industry leadership, product reception, team morale, development predictability, product quality and overall results. Several examples follow.

Five Sample Engagements:

1. Creating business strategy and defining strategic product plans. Frequently a new senior executive or a recently promoted one is assigned the task to define a new, disruptive company or divisional strategy and to create an enabling product plan around it. Often the existing team is struggling to “think big” or to consider game changing possibilities and the best approach is to bring in an outsider to help broaden the discussion, provide a fresh point of view and inject a “can do” sense of confidence into the process.

This type of engagement is a bit unpredictable, depending on how open ended is the solution set. Sometimes the baseline constraint will be remaining in the same market, but with a transformed product set. Other times it will be to take the lead in an emergent market, or to define an entirely new solution space. Typically, since we deal primarily with technology companies, there will be a fresh new emergent technology wave coming and it is not clear how that wave will affect the existing business or market (see story “Leading the Parade” on the Anecdotes page of this website). These are opportunities in disguise and the challenge is to identify the one (or ones) that best fit the company, the team and their skills, and the new leadership, or else to consciously choose to revamp those things as well.

Once the strategy is settled and the product planning is beginning to take shape, the challenge shifts to adoption. It is now time to begin the transition to execution. This may require evaluating and selecting a new set of technologies, hiring of a new team of domain experts, retraining existing staff, or even restructuring the organization. These things require careful consideration, as the team may already be struggling to adjust to the new executive’s leadership style. It is crucial to avoid common pitfalls in strategic planning such as taking on too much at once, which can be overwhelming for many people, or not taking on enough which dooms the process early on. This is where executive leadership, guidance and vision are essential.

Slotnick Systems has consulted in many aspects of these strategic processes, including:

  • Aiding the executive to plan and lead the overall process
  • Proposing and refining specific product requirements and plans
  • Analyzing market opportunities
  • Recommending the best emerging and existing technologies
  • Evaluating alternative architectures and designs
  • Balancing agile methods against traditional approaches
  • Identifying and recruiting the right skilled product design architects and senior staff additions
  • Staffing new engineering teams
  • Locating, planning and preparing new development centers in new locations as required (both teams and facilities)
  • Introducing the core team to key industry, technology and market leaders
  • Building relationships with third parties

If this sounds like the type of major new undertaking your organization is considering, Slotnick Systems can help.

2. Overall engineering team assessment and improvement. This type of engagement involves the examination and redesign of software development team processes, engineering behaviors, tools, product strategies, and individual responsibilities and team structures. Processes must be right sized, people must observe improved behaviors in order to learn them, using the wrong tools can waste a lot of time and effort. Putting the right person into a key role can energize an entire organization. Redesigning such fundamental elements of a product team often involves changes to company culture. These cultural changes include injecting a sense of pride, a drive for urgency, a belief in the achievability of success, and the empowerment of an independent spirit amongst the team members. I have found that this type of change is best driven from within the team through the recognition and encouragement of key individuals who embody elements of those traits. Another key ingredient is the demonstration of desired practices, attitudes and behaviors by all senior management. Change involves everyone. It is not uncommon to find that many outstanding improvement ideas are known by individual engineers and they only need to be asked their opinions.

3. Agile/scrum process improvements. Often an agile/scrum process is in place, but management is not satisfied with its predictability. Program management is often disconnected from the actual scrum teams and the scrum leads are not utilizing adequate knowledge of the product deliverable requirements in determining scrum cycle content or timing. Testing plans and validation cycles are not providing proper code coverage. A Release and Integration team may not be completely in sync with the rest of the larger team and the project as a whole. Overall project schedules tend to be unpredictable, and the full content contained in releases is not known until the release timeframe when final adjustments are made. Likely causes: the inadequacy of requirements documentation, the inability of program managers to drive the program forward by directing weekly decisions, too many scrum teams, and ambiguous ownership of overall program activity coordination and project delivery. I have found that a coordinated set of improvements to process definition, process enforcement, behavioral patterns, clarity of responsibility ownership, timely requirements documentation completion, leadership changes, and synchronization of scrum methodologies can be effectively utilized. The creation of training programs can also prove instrumental in coordinating these improvements.

4. Separation of open source development from product development. Many projects are open source based, but not all of the content delivered in the associated product will be contained in the upstream code. Some will be proprietary and some will be too device or product specific to be appropriate for upstream contribution. Progress must be made continuously and in parallel on both the product software and on the upstream development. Often product priorities cause management to require the open source developers to disregard their open source commitments and focus on product problem resolution. Likely causes: a lack of clarity of project goals, inadequate project wide communication mechanisms, the degree of prioritization of open source as a key ingredient in company success, and an imbalance of resources between open source and product teams. Some solutions I have used are these: physical and/or geographic separation of the teams, configuration of the developer tools to enforce rules including separate authorization to different parts of the code in the version control system and separation of issues in the issue tracking system, and a combination of leadership and behavioral changes across the entire organization.

5. International engineering team coordination. Either by design or through merger, many engineering departments find themselves with one or more international development teams and product delivery challenges related to executing a synchronized product delivery plan. Poorly coordinated efforts can result in missed schedules and lost revenue. I have managed multinational development teams on four continents and have seen and corrected many problem scenarios.

Often the first problem is the work assignment. Finding the right size project for remote teams is fundamental, and assessing a remote team’s capacity to work independently is a basic step in identifying the right project breadth. Program management must be constantly diligent to anticipate issues as progressive project phases require timely component deliveries, perhaps from many locations. Dependency matrices must be worked and baked into the plan. Engineering development tools must scale accordingly and allow for international use. Many companies select a functional split between geographies, (i.e., do development engineering in the US and do quality assurance in a remote international location, typically India, China, or Brazil) in order to enable around the clock forward progress.

I have found this type of functional split to often be a poor choice because, 1) quality assurance requires many points of contact between teams resulting in time zone related communication delays, 2) defect triage sessions are difficult to do across locales and language issues can get in the way, 3) Quality engineering and development engineering should be very closely coordinated with engineers and testers sitting next to each other. Well defined project components or entire encapsulated subprojects are best to consider for remote development. Remote site project encapsulation allows development teams to be self directed and to have minimal dependencies on other teams. They allow remote teams to manage their own schedules, to identify and correct team issues as they become apparent and often have a positive side effect of improving morale. In a functional approach the first person to recognize an issue might be a program manager in a different location. With encapsulated subprojects a remote team should see the issues immediately.

With this type of engagement, Slotnick Systems assesses team capabilities and talent pockets, identifies independent workers, creates a plan for a more empowered and effective international engineering team structure, suggests development tool adoption, and provides staffing recommendations. If desired, Slotnick Systems will manage the execution of the plan to completion and first product shipped.

© 2019 Slotnick Systems, LLC. All Rights Reserved.