Platt Perspective on Business and Technology

Business planning from the back of a napkin to a formal and detailed presentation 3

Posted in strategy and planning by Timothy Platt on January 21, 2016

This is my third posting to a series on tactical and strategic planning under real world constraints, and executing in the face of real world challenges that are caused by business systems friction and the systems turbulence that it creates (see Part 1 and Part 2 for earlier installments to this series, with those two key terms defined and discussed in Part 2.)

Business systems friction, to repeat a key set of details from Part 2 as a starting point for this posting, arises as a consequence of information and communications systems inefficiencies and failures in organizations, as they seek to function productively. There and for purposes of this discussion, “organization” can be construed as a wide-ranging term that covers specific businesses directly under analytical review, partner businesses that they would seek to collaborate with through supply chain or other mutually supportive systems, and the marketplaces that they seek to bring value to through business transactions. Friction can and does arise in all of these entities, and its collective impact from all of these sources, on other organizations in overall business systems constitutes economic systems friction. Turbulence arises as a consequence of friction at the business organization level, and it serves as a cause of its perpetuation there. And I add here that turbulence as so characterized at the single organization level, has its direct counterparts at the higher multiple-organization and overall economy levels too.

Focusing on all of this as it arises and plays out at the level of the individual organization, I stated at the end of Part 2 that I would continue its discussion here with a focus on the constraints that lead to friction and on addressing them so as to control and reduce its occurrence. And I went on to note that my focus in this would be on:

• Reducing turbulence when significant levels of friction do arise in process execution or in its planning.

And I added that I would begin adding in those constraints to the baseline friction-free model of Part 2. And as a part of that I would discuss after-the-fact, post hoc review and learning curve issues and processes for moving forward, and particularly where it has proven necessary to make one-off and ad hoc decisions and then deal with any unexpected consequences that result from them.

I begin that line of discussion by noting that I wrote Part 2 in primarily abstract terms, but I turn from that here, to consider more specific strategic and operational processes and the decisions that lead to them. And to set some ground rules for that, I start by acknowledging that friction per se is not a simple binary, all or none phenomenon and either for its occurrence in given business processes, or for its creating impact on business performance and efficiency.

1. Friction per se can best be considered as arising at the level of specific processes and process implementations, and certainly when an effort is being organized to identify and remediate specific sources of it, and to limit the turbulence that it creates.
2. While every business process implementation can be expected to be shaped by at least some measure of friction, and every business process as a template for action can be expected to be prone to the challenges that friction creates when implemented, the inefficiencies so generated do not always rise to a level of significance so as to impact upon the business as a whole, and most business processes would at most only occasionally generate significantly problematical implementations at all.
3. Start by looking for and analytically identifying and understanding any process implementations that do arise to a level of significance so as to cause overt problems and either for the business as a whole, or just for some functional area of it. Look for the processes that are more likely to generate these threshold crossing implementation events. And start by assuming that any business has some that would, and even a collection of such high risk processes in place, even if none of them happen to be exploding or melting down in specific failed implementations right now at this moment. Start out assuming that that is just waiting to happen, and at what from a risk management perspective is at too high a likelihood of occurrence to be acceptable. (Risk management is built upon a foundation of prudent pessimism.) And remediate problem processes so identified.
4. Then, moving ahead in this progression of risk management ground rules, as you identify and address the highest-risk, most likely to fail processes, and as you address any current problem implementations coming out of them, move on to the next most significant and likely set of problematical processes, and address them in this same way. And keep working your way down this priorities list, while looking for new and emergent problems of a higher threat level value that should be moved to the top of your to-remediate list too. (Risk management is grounded in an assumption that potential problems can be identified and remediated before they can erupt, so it is built upon a foundation of prudent optimism too.)

But let’s drop that fourth step from consideration, at least for the moment and consider an implementation of the first three. And I will frame this in a specific scenario-based context, and one that has both strategic and operational roots:

• You own a small but growing software company that produces apps for smart phones and tablets in support of commercial enterprises, and with a primary focus there on retail businesses. This is a good market to service because essentially every retail business has found it necessary to be online, and interactively so and in ways that work on the small screens that their customers are all coming to rely on. And essentially all of your customers: all of the retail businesses that buy custom-built apps from you in support of their commercial success, need new and significantly updated apps at the end of the year that they can market to their customers and potential customers to draw in their business, going into their year-end holiday sales cycle. These last weeks of the year, I add, are the make or break sales period for many of these businesses for the entire year as they represent the timeframe in which they expect to make a very significant percentage of all of the sales that they can complete in the entire year, and even as much as a third of that total. So the period leading up to this is your make or break period as you complete production and testing of all of these new apps, and both in-house and in the context of the purchasing business’ networked servers and related information technology infrastructure. Some of that is going to be maintained in-house by your business clients themselves and some is going to be hosted and run through third party networking service and server support businesses, as part of larger cloud service offerings. You apps have to work in both contexts, and you need your programming and quality assurance testing staff to be working at their best for all of this.
• You also have on staff, a large number of people with expert level skills and experience that are highly sought after, and both in your business sector and by businesses in general that need experts in the cutting edge coding technologies that your employees know and use. So you work hard to both attract and retain the right people for your company and a big part of that is in how you offer vacation days, personal days and sick days. And this is approaching the holiday season and a number of your key people have decided to take off now. This would not necessarily be a problem as you have built strategic strength in depth in your product development team. But now, with these people off and unavailable and with your staffing margin reduced and everyone there really needed, your entire community is hit with an early and particularly virulent form of the flu – and you find yourself unable to maintain a coding and testing staff that is adequate to meet your immediate and pressing needs. You are contractually obliged to get all of these apps out of your door on fixed deadlines that cannot be extended because your client businesses need them Now! And you are facing a single point of failure of a type that I have been discussing in detail in a concurrently run series: Rethinking Exit and Entrance Strategies, and particularly in its Part 2 and following installments (see Business Strategy and Operations – 3, postings 559 and loosely following for that series’ entries.)

I have been addressing these issues in that series from the perspective of better understanding strategic and operational problems per se as they arise and have to be resolved. I look at them here from the perspective of the friction that leads to them and that they in turn cause. Viewed from the perspective of my exit and entrances strategies series, a discussion of this example scenario would focus on how time off from work is actually operationally scheduled, for better maintaining critical skills availability in the face of potential unscheduled employee loss and from whatever cause. Sick time off cannot be planned for in advance, but vacation time and personal days off can be. And that means coordinating time-off schedules to make sure that too many employees with the same critical needs skills sets are not going to be away from work at the same planned time, as a baseline for who is and is not going to be available for work. Viewed from the perspective of this series and its line of discussion, this scenario is all about workplace and business systems friction and more effectively communicating and negotiating needs, and both of the key employees involved and of their supervisors and the business they work for. The more effectively, and amicably friction can be forestalled here through advance scheduling management for this time off, the more smoothly these personnel issues can be handled and with less long-term turbulence generated in the process too.

I am going to continue this discussion in a next series installment where I will continue pursuing my to-address list from above:

• After-the-fact, post hoc review and learning curve issues and processes for moving forward, and particularly where it has proven necessary to make one-off and ad hoc decisions and then deal with any unexpected consequences that result from them.

Meanwhile, you can find this and related postings and series at Business Strategy and Operations – 3, and also see Page 1 and Page 2 of that directory.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: