In helping you get focused, get on track, and get back to profitable growth this blog is part 6 of a 12 part series providing more detail supporting the Business Change Flow presented on my web site, Center for Managing Change.

The previous blog in this series talked about 7 Important Reasons For Business Change Flow Having A Schedule. Now, let’s turn our attention to 3 Reasons For Having Technical Goals, Test Plans, and Design. Getting back to profitable growth requires achieving specifics, specifics that reflect the goals set in the business plan. These goals, say 8% increase in in-bound marketing sales, are achieved through improved functional performance. In turn, the functional performance is reflected in the technical performance.

It is imperative what is considered acceptable performance from a technical perspective maps directly into acceptable performance from a functional perspective.

To insure this happens technical excellence needs to be addressed at 3 levels:

  • Technical Goals
  • Testing
  • Design

Now, the 3 levels are placed in that order to help insure:

  1. Cohesiveness. A coherent, guiding frame of mind is needed that flows from the general to the specific is needed.
  2. Reference – Technical. The team members are provided with a mechanism to which they can refer when dealing with the eventual technical and implementation challenges that surface requiring a re-set or re-calibration of their approach.
  3. Reference – Functional. Also, organizing the technical in this manner gives the team a clearer audit trail for when they are chasing down poor performance or need a reminder as to why a particular function is important.

From Technical Goals To Test Plan To Design. “Where’s all this going?” is a question you, as the leader, need to be able to answer in a comprehensive manner that is definitive, e.g., if I can expand on the example given earlier, “8% growth in gross sales and an increase to the bottom line of 2%.” Notice that was a functional answer NOT a technical answer. That’s appropriate. The technical goals are left to your technical leads to create. Now, if you are wearing multiple hats maintain the discipline of clearly defining the functional goals before diving into the technical goals. This can take some discipline. What can help is laying out a flow that goes, in a general sense, like this:

Business Plan goals ➔ functional goals ➔ (functional) Users Acceptance Test  ➔ design goals ➔ design test plan ➔ design specification ➔ design implementation plan ➔ plan execution ➔ technical test ➔ user acceptance test ➔ sign-off.

Working in this manner has the best odds of getting the most done, correctly, with the least amount of effort in the shortest period of time. Now, this does not mean everything will go right the first time. Rather, it means when there is a lack of performance everyone knows how “out of spec” the results are and they can work to correct the situation being guided by the higher functions reflected in the accepted flow. Recovery from any mistakes can actually generate a sense of triumph among the team members which leads to greater unity and commitment to quality performance.

In order to create a good design effort a Project Scope of Work is needed. To learn more about this read the next blog in this series, 5 Steps For A Successful Project Scope of Work.

Also, for more information regarding change management and how you can get your arms around it download my free e-book, Mindset – 5 Simple Ways To Look At Complex Problems.