How to Compete and Win Like NASCAR’s Jimmie Johnson

It’s almost impossible anymore to compete on product innovation, supply chain efficiencies, technology adoption, aggressive sales and marketing, pricing power, or organizational/functional structure.  Because of the ubiquity of technologies like the Internet, ERP/CRM systems, business reference models, and management frameworks, your competitors have access to the same resources and tools as you do.  Location MIGHT be an advantage if there is no physical room for your competitor to sell or operate.  But if location is irrelevant to buyers in your market, it makes no difference where you’re located.

Information travels immediately.  Everything seems to be mobile-enabled.  Logistic resources are globally available.  Central bank’s quantitative easing, crowd-funding, micro-funding, and even the proliferating pawn industry have saturated capital markets – assuming you’re creditworthy.  Off-shoring, remote workers, and the fast-growing “Free Agent Nation” of contractors and solopreneurs keep driving down human capital resource costs while offering more to choose from.

There is almost nothing unique or proprietary about your business or process model.  Over the past several years, a focus on “best practices” has led to the development of process classification frameworks, identified workflow patterns, business data models, organizational structure business models, and management frameworks.  Every ERP or CRM software vendor provides well-vetted features, templates, and tools that align with all these models.

Competing in business today is similar to competing on the NASCAR circuit.  The rules are written to constrain car owner’s ability to introduce or maintain any technological advantage for any reasonable duration.  Limits are placed on nearly everything so the only significant variables left are the competency of the driver, the pit crew and the management of a defined and measured set of expendable resources: fuel, tires, and driver/pit crew health.

All that’s left is competency of execution.

It’s interesting to note that any driver can win any race on any Sunday if everything comes together one time.  But the goal they’re all shooting for is winning The Sprint Cup, which is to accumulate the most points by the end of the year.  A driver/team can win the Sprint Cup while never winning a single race during the season.  But if they consistently finish in the top 10 in every race, it’s their best chance of winning The Cup.

NASCAR’s rules and regulations make it almost impossible to compete on anything other than execution.  All teams operate under the same constraints.  If you think about it, the only reason to explain the perennial success of recent 5-time Cup winner Jimmie Johnson is his (and his team’s) ability to consistently and competently execute strategy and process.

Take a hint form NASCAR.  Rather than devoting money and effort trying to gain a competitive advantage from ubiquitous and constrained resources, focus instead on the pursuit of execution perfection.  The ability to consistently execute processes at a high level of competence is the only reason I can think of to explain why Jimmie Johnson has won the Sprint Cup – five times in a row.

Image courtesy of http://nascarjc.wikispaces.com

A Simple Tool for Managing Project and Process Risk

Thorough, complete, and accurate definition of a process should always include the identification and analysis of all risks associated with successful process execution.  The same thing applies in project management.  Nearly any effort, whether process or project-focused, is going to be exposed to some element of risk.

It’s the job of Process Owners, Process Managers, and Project Managers to identify, analyze, and address risk.  Unfortunately, many managers don’t have the benefit of a structured framework and simple tools to help them.   Because of this, risk management often falls to the bottom of the priority list.

I see examples of this all the time, especially in Charter-type documents such as a Process Improvement Charter or an IT Project Charter.  Most of the time, the “Risk” section of these charters are either blank, read “TBD,” or contain a few general statements.  Most of these statements are simply declarative.  For example, “There is a risk of the project finishing late,” or “Raw materials may not arrive in time.”.  The problem is that by only declaring that a risk exists contributes little to the strategy and execution of managing that risk.  In other words, declaring a risk is only giving it a name, nothing else.

Managing risks involves identifying and addressing the following key factors:

• What’s the situation causing the risk?
• What adverse consequence or consequences could possibly result from the situation.
• What’s the impact.  Or, if the bad thing happens, how bad can it be?
• In the beginning, what’s the probability (likelihood) of the bad thing happening?
• Now, today, what’s the probability of the bad thing happening?
• What’s the mitigation strategy?  In other words, what are all the actions you can take to mitigate or reduce the probability of the bad thing happening?
• What’s the contingency if the risk is realized?  If mitigation efforts fail, what will you do if the bad thing happens after all?

Once all of the above has been considered, managing risk should be easier.  One of the keys is to keep things simple, yet focused.  To that end, a few years ago I developed a simple spreadsheet that helps me identify, qualify, quantify, anticipate, contain, prioritize, and prepare for responding to risk.

The spreadsheet is just one one of the sheets in a workbook I call my “PM Dashboard” where I keep track of my:

• Prioritized To Do List (with a built-in prioritization calculator)
• Project Issues Log
• Project Action Items Log
• Project Change Items Log
• Questions Log (lots of things need answers)

For the time being, I’m offering this Risk Management Worksheet for free.  Download your copy here:  RiskManagementMatrix

What’s Wrong With the “Track” Software Requirement?

On software requirements lists, I often see a requirement statement beginning with, “The system should have the ability to track…”  Then, the statement specifies the object of the tracking.  Data objects, such as invoices, payments, or service records are commonly named in these types of requirements statements.  And what’s usually “tracked” on these objects are either changes in object life-cycle phases or quantity increase or decrease computations.  For example, a specification might read, “The system should have the ability to track product sales by sales rep.”  This is a weak requirement statement and has little value.

My problem with this type of requirement specification is with the verb “track.”  For one, all software programs “keep track” of data.  Frankly, it’s a bit superfluous to define a software requirement by specifically identifying a particular data object that must be tracked.

The “track” specification is deceptive.  What it hints at is the set of management processes that are often missed or ignored by many IT Business Analysts (BA).  The reason why these processes are often ignored is because IT BAs don’t usually have any significant management experience to draw from.  Therefore, they struggle to understand that work performed by managers is simply the execution of specific processes designed to plan, organize, lead, and control work in other processes.

The definition of a management process is defined by the primary process performer and the categorical scope of tasks within the process.  With management processes, the primary human resource who performs the majority of process tasks usually has a functional role title of Lead, Supervisor, or Manager.  The four basic categories of management processes are:

• The Processes of Planning
• The Processes of Organizing
• The Processes of Leading
• The Processes of Controlling

Most of the time, work associated with tracking/keeping track falls into the Controlling category.  To “track” is to be or to stay aware of, to keep informed, to watch, inspect, or measure.  Control starts with awareness.  Once aware, the manager can determine if an adjustment needs to be made.

All of this implies that, as a result of some situation, condition, state of being, or other trigger (an “event” in process engineering terms), a manager will take action.  With the “track” software requirement specification, it’s usually referring to the need to enable or automate the awareness.  In other words, there’s a need for a manager to be alerted about a threshold – so the manager can subsequently invoke the adjustment: a controlling task or process.

Given this reality, anytime a BA is tempted to write a “track” statement, he/she should not.  Instead, the BA should work to identify the management processes of planning, organizing, leading, or controlling.  The questions to really be asking are:

• Why should the data be “tracked?”
• What does “tracking” enable the business to do?
• What if the business doesn’t “track” the data?
• What process does “tracking” support?
• What role “tracks”?
• What is the full scope of “tracking?”
• When does tracking start?
• When does tracking stop?

Realistically, the “track” specification is trying to communicate a need to support a process performer who usually has the responsibility to:

1. Watch, view, inspect an accumulation or movement of data
2. Recognize a threshold condition before, during, or after it’s reached
3. Diagnose, determine, or decide on a subsequent action or effort
4. Execute the subsequent action or effort

Each of the above steps describes distinct effort. Collectively, they describe a typical management process associated with the work of controlling a process.  “Control” is a verb that implies action.  Thus “control” performed by a manager almost always involves specific effort. Given this perspective, the track specification can be better elaborated with a set of software requirements specification statements such as the following:

• The system should calculate, store, and display on demand the value of the percentage difference between the dollar value of the Invoice and the dollar value of the sales rep’s forecast amount.
• The system should have the ability to alert the Sales Manager whenever the value in the Total Amount field of an Invoice record exceeds the the value in the Forecast Amount field on the sales reps’ weekly forecast record.
• The system should have the ability to execute the alert (described above) by simultaneously sending an E-mail and a text message to both the Sales Manager and the sales rep.

These statements specify more than the generic term, “track.”  The statements relate more closely to specific processes performed by a manager.  It’s another example of why all software requirements should originate from defined business processes.  After all, the only thing that software actually does is automate process tasks.  A requirement with no traceability to a process is a useless waste of information.

Your Process Stakeholders Know a Lot Less than You Think

(Part Three in the series “Is Current State Modeling a Waste of Time?”)

In “What’s Your Process Intelligence Level?,” I explain that I’ve never worked with a Process Manager who had a comprehensive, in-depth, and completely accurate understanding of all the processes he/she was responsible for.  The same can usually be said about the people who perform those processes.  Sure, there are the so-called Subject Matter Experts (SMEs) who act and talk like they know more about the process than anyone else.  But in my experience, at the lowest level of process detail, most SME’s knew much less than what they thought they did.  They may know more than everyone else, but they still don’t know enough.

As for everyone else, the range and depth of process knowedge often varies widely from person-to-person.  And that is one of the root causes of process execution problems.  In other words, processes typically don’t fail because performers deliverately execute incorrectly.  Processes fail to execute properly because performers don’t completely understand:

(a.)    How the process is supposed to correctly execute
(b.)    What the performnce standards are for both the process and for them as individual performers

At first, few Process Managers want to believe that their department’s performers are that ignorant.  Or that there’s as much knowedge inconsistency as there actually is.  But a few simple exercises can quickly validate my assertion.

First, I suggest that the Process Manager attempt to verify/validate the SME’s knowledge.  And the SME I want him/her to challenge, is the SME the Process Manager holds in the highest regard.  I have the Process Manager engage in a one-on-one discussion where the Process Manager simply asks the SME to “walk me through” the process, in detail.  Every single time this exercise has been conducted, both the Process Manager and the SME have been surprised.  Never has an SME conducted an end-to-end process explaination without:

(a.)    Admitting they don’t know some (or many) important details
(b.)    Identifying or exposing persistent , but neglected, process execution problems
(c.)    The SME and Process Manager disagreeing on a few, if not many, process execution details

Next, I suggest that the Process Manager bring all process stakeholders together to attempt to verify the Process Manager’s assumption that everyone knows everything they should know about the process.  Have the SME lead the discussion.  Then, sit back and watch what happens.  See if the collective knowledge is thorough, complete, and accurate.  See if everyone, or at least the process performers, agree on everything.

Every time I’ve witnessed this approach, the Process Managers and Owners have been alarmingly surprised by the extent of knowledge gaps and lack of consistency of execution among process stakeholders.  Debate focuses on both the design of the process (how the process should execute) and the actual execution of the process.  And these discussions nearly always expose process problems that require immediate resolution.  At this point, emphasis begins to shift from dreaming about the utopian future state to doing whatever is necessary to stop the bleeding today.

What’s Your Process Intelligence Level?

(Part 2 in a series.)

In part one of this series, I listed eight reasons to justify modeling current state processes. I addressed an argument that often comes up when working on software development or process improvement projects.

A lot of times, organizations are in a big hurry to get moving with a solution.  They’re convinced that spending time on defining current state is a waste of time.  They believe they’ve already identified the root cause of their problems and want to hurry up and get started on what is usually a hastily decided solution.  And that, unfortunately, usually involves premature capital spending on technology.

In this rush to nirvana, it’s often a rush to fix the wrong thing. Thus, time and money is wasted, the real problem never gets solved, and often, the real problem is intensified.  In other words, they pay too much for something they should not have bought in the first place.

In situations where I’ve either been given the opportunity to focus on understanding the current state, or have been able to carve out time without impacting the project schedule, I’ve never worked with a manager who had a comprehensive, in-depth, and completely accurate understanding of all the processes they were responsible for.  At the very least, an in-depth understanding involves knowing:

•    Every discrete process within their management domain
•    The qualifiedly and quantifiable goals and objectives of each process
•    The qualifiedly and quantifiable inputs to, and outputs from, each process
•    The exact sequence of steps taken during the execution of each process
•    The specific resources (human and/or machine/computer) responsible for executing each step
•    The precise data that must flow within each step
•    The acceptable speed or rate of effort expended in the performance of each step

In some cases, I’ve worked with managers who knew a lot of the above information, but never have I worked with one who knew it all at the levels described above – at least at first.   In every case, it didn’t take long for the manager to realize that the first step in process improvement was to improve his understanding of the processes within his scope of responsibilities.  Many times, I’ve been initially engaged on a project to help a manager train his employees to improve their process execution competency.  In order to train the people, I needed to know the level of detail listed above.  When I’d begin to ask the manager for this information, that’s when we would both begin to realize how little the manager actually knew.  But to the credit of nearly every manager I’ve worked with, they were quick to admit and accept this knowledge gap, and equally as quick and enthusiastic about accepting personal responsibility for closing the gap.

If you’re a process manager and want a method for testing your own level of Process Intelligence, follow the instructions below.  While this quick self-test can’t compare to a full-blown, formal process management maturity assessment, it can give you an initial idea of the gap you’re facing.  If you do want to take it step further, simply use your favorite Internet search engine to search for the phrase, “process management maturity assessment” and you’ll find links to some assessments.  Or, you can follow this link to download a preliminary draft copy of my extensive process management assessment spreadsheet.

PROCESS INTELLIGENCE QUICK SELF-TEST:

a.     Time yourself on this one.  Take out a piece of paper, and as fast as you can, make a list of every process you’re responsible for.  If you can’t do it within about 15 second or less, that’s not good.
b.     Compare your list to the Process Classification Framework.  See how many you forget or should have more granularly identified.
c.     For each process you manage, list at least three specific, quantifiable measurements.  Allow yourself no more than 5-10 seconds for each process.
d.     For each of those measurements, define the specific situations, times and places where you deliberately and consistently measure them.
e.     Think back to your first day on the job as the process manager.  Did you begin measuring on Day One? If not, when did you start?  How does today’s performance compare to your Day One measurements?
f.      Within ten seconds, can you access all the current, accurate documentation that exists for all the processes you manage?  Do you think everyone else on the team can?  What makes you so sure?
g.     For each process, make a list of every single “data object” that participates in the process.
h.  Then, for each of these objects, list their individual elements.  (For example, an Invoice is a data object.  Elements of an Invoice are things like the Invoice number, the date, customer name, line item, price, discount terms, etc.).  Remember, most business processes involve data processing, which includes creating or inputting new data, recalling or reading stored (existing) data, changing or updating existing data, and sometimes, deleting data.

If you can breeze through the above list with ease and accuracy, you might just know enough about your processes to effectively start looking at the future state instead.  But that would only be if you don’t expose an existing process problem that requires an immediate, temporary (or permanent) resolution.  In any case, if you can’t breeze through the above list, there’s a strong probability that your “solution” will take a lot longer to realize, will cost much more than it should, and won’t likely fix the problem to the degree that you’d hoped for.

Is Current State Modeling a Waste of Time?

(Part One in a Series)

We live in a world of instant gratification and quick fixes.  In business, competitive pressure escalates relentlessly.  Money’s tight, time’s limited, and everyone’s impatient.  Regardless of the country or culture, business leaders’ prevailing attitude is to hurry up and get working on the fix.  Any action is better than no action.  We can afford any waste that results from our haste.  The end is certain to justify the means.  We’re too big to fail.  This time it’s different.

That’s why, when it comes to defining software requirements, or embarking on any type of process improvement initiative, focusing on today’s situation isn’t considered a good use of time or resources.  On nearly every project I’ve worked on, I encounter some resistance toward the work of defining the “as-is” or “current state” of processes.  Sometimes resistance comes from the project sponsors.  Sometimes it comes from process owners, process managers, and other subject matter experts (SMEs).  And sometimes it even comes from project managers and business analysts within the project team.

Too many process stakeholders think they know the full breadth and depth of current state issues and problems.  They think know how and why those problems started and why they persist.  Too many meetings, discussions, and E-mails have beaten the horse to death.  Many times, organizations are so sure of the problems – and the likely resolutions – that money has already been spent and resources have been deployed to start working on the resolution. All resources and activities are focused on the future, on the great vision of the fully-optimized future state.  Devoting any more time and effort to the current state is analysis paralysis.  “We’ve survived this long, we can survive a little while longer,” is the tragic belief.

However, the current state is always in a lot worse shape than anyone realizes – or might be brave enough to admit.  And it’s not likely to change any time soon, regardless of how aggressive the transition plan is.  Unless the entire organization (not just  a few change management “gurus”) has a lot of experience in successfully implementing large-scale business model or process changes,  the odds are stacked against this project finishing on-time, within budget, and with results closely meeting or exceeding expectations.  Realistically, few organizations can claim organizational change as a core competency.  Sadly, for most organizations, it’s a core incompetency.

From this perspective, it means that anytime is a good time to model the current state.  That’s because current state processes have problems currently causing customer dissatisfaction, waste and lost profitability.  Until the future state is reached, these problems will persist.  In reality, there are plenty of reasons to model current state.  In addition to simply being a means for identifying improvement opportunities in general, the following lists more reasons to justify defining, modeling, and documenting current state:

A.  You Know a Lot Less About the Current State than You Think You Do

B.  Your Process Stakeholders Know a Lot Less than You Give Them Credit For

C.  You Need to Stop the Bleeding Today

D.  You May Not Live to See the Future State

E.  You Need a Baseline for Measuring Progress and Return on Investment

F.  Process Stakeholders Need and Want a Change Roadmap

G.  Your Current State is the Future State

H.   Some Things Can’t be Changed – What Might They Be?

In subsequent posts, I’ll take an in-depth look at each of these reasons.

Too Much Process?

Awhile back, I was in the middle of qualifying and proposing a process improvement project for a large insurance company in the USA.  The company was looking to staff a team of process improvement specialists like myself.  As part of the proposal and selection process, the company had candidates “interview” with two or three different managers and at least one peer.   In this case, the peer was a Process Analyst in another division.

One of those questions posed to me by this “most senior” Process Analyst was, “Can there be too much process?”

At first, I thought it was a trick question. “Too much process WHAT?” is the first thing that popped in to my head.  Too much process definition?  Too much process design?  Too much process analysis?  Too much process measurement?  My instincts and experience told me not to challenge him too hard.  Most managers are woefully under-skilled at interviewing so I certainly don’t expect the average staff person to be any better.

I assumed he was really trying to ask me a set of questions.  Should every single business process be designed, executed, measured, and controlled?  Maybe he was trying to ask if all business processes require structure, focus, discipline, and accountability.  Or if there are any processes that can be allowed to execute inconsistently, without forethought of design, or with little or no risk of quality problems?

When I asked for clarification he struggled to re-phrase.  After fumbling a bit, he finally managed to communicate what he meant.  He was simply trying to ask if I thought some processes could be too rigidly designed, executed, and managed.

First, I told him that I think it’s difficult to quantify “too much” or “too rigid.”   Particularly if “just the right amount” (of rigidity) has yet to be quantified or put in context.   But to let him (and his dopey question) off the hook, I simply gave the age-old cop-out answer, “It depends.”

The less structured, focused, disciplined, and accountable an organization is, the more immature it is with regard to process management competency.  For these organizations, there is such a thing as “too much process.”  There’s no such thing in maturing organizations.

The Business Process Assessment Worksheet

One of the information products I’ve been working on is the Business Process Assessment Worksheet, an extensive, eleven-page tool for assessing a wide range of process management topics.  I started this worksheet while I was working on a process modeling and documentation project.  One day, as I was modeling a set of customer service and support processes, my Client’s project executive/sponsor asked me, “Compared to other Clients you’ve worked with, how would you compare our process management discipline?”

At first, I was tempted to quickly offer what could only be a subjective opinion.  My relationship with my Client was solid and I’m sure my opinion would have some credibility, but I wanted to give the executive an answer that was both quantitative and qualitative.   I knew of such things as process management capability maturity models but I felt that most of them were too high-level, generalized, and lacking in-depth measurement criteria.

I gave the executive copies of the process management capability maturity model documents I found on the Web, then began working on a more comprehensive assessment tool.  Unfortunately, the executive left my Client’s company before I had a chance to give it to him.  I really would have liked his feedback.

Recently, after reading the inspiring article, “Architecting the Social Information Experience,” by Andrea Ames and Alyson Riley (from The Society for Technical Communication’s Intercom magazine), I decided to try a social media experiment where I’d offer this worksheet as a free resource, possibly only for a limited time, with the hopes of receiving some feedback.  Someday, I may sell the worksheet.  But for now, I’ll give it away.

You can download a .pdf copy of the worksheet here.  Or, go to my Web site, www.process1st.com, and download it from the sidebar link.  If you’d like the original Excel spreadsheet version of the worksheet, please go to my Contact page on my Web site where you’ll see my E-mail address.  Just send me an E-mail and I’ll reply with the spreadsheet attached.  Remember, this offer is for a limited time only.  And I really need your feedback, so even if you only get the .pdf file, please E-mail me and let me know what you think about its value.

Process Assessment Worksheet

Process, Procedure or Policy?

I’m often asked, “What’s the difference between process and procedure?”  This question also comes up in discussions with other Business Process Management professionals.  In fact, when this question was raised in one of my LinkedIn process management groups, it sparked a vigorous debate among participants who, in general, seemed obsessed with coming up with the perfect, definitive, once-and-for-all answer.  Only one answer made any sense.  One bright commenter suggested it’s simply a matter of personal choice.

Googling “process vs. procedure,” gives you more than 65 million results.  That’s a lot of opinions.  Only one matters.  Pick your words, decide on definitions, make sure the words fit within and make relative sense in a deliberate, defined structure of definitions.  And be relentlessly consistent in the use of those words.

Below are my definitions:

Policy = the strategic “what”

Process = the higher-level tactical “how”

Procedure = the lower-level tactical “how”

Activity = a set or group of tasks, typically performed by one performer or entity; Procedures consist of Activities

Task = individual, discrete, instances of effort; a step performed in series;  Activities consist of a series of tasks

The point is, there is no industry standard definition for each of these words.  When it comes to your organization’s process modeling/documentation standard, what’s important is structure and consistency.   Make the effort to identify the words.  Develop reasonably logical definitions.  Openly and widely communicate those definitions.  And if you have any leadership responsibilities within the process modeling, documentation, or improvement initiative, be the leader who encourages everyone in the organization to stay disciplined in their consistent

Software Requirements Traceability and the Mythical SME

In my previous posts, I describe my reasoning on why I assert that the true origin of a software requirement is, and can ONLY be, a process.  Quite simply, software is a resource that participates in a process.  In general, there are only two broad categories of resources:  people and machines.  And from this perspective, the words “software” and “technology” are synonymous with “machines.”  What the software is required to accomplish during an activity or task within an activity (the lowest level of process decomposition), can be considered the ‘software requirement.’  Therefore, the origin/root/foundation of any ‘software requirement’ related to the execution of a process IS the process.

In my 20+ years in management and IT consulting I have seen dozens of software requirements documents and document sets.  Where traceability of software requirements is mandated, I have never once worked with an organization that collectively understood that the process is the origin of the requirement, not the person describing the process.  What they confuse is the simple construct that the process is the origin of the requirement,  but the person (“The Enlightener”) is the source of information that enlightened the business analysts about the needs of the process.

Managed requirements in these organizations wrongly focus on the content of the statement made, and the time and place it was made by the Enlightener.  When the Enlightener is the focus, this implies that one of the primary purposes for maintaining formal software requirements documentation is for defensive posterity  reasons, rather than as a QUALITY control tool.

The quality point isn’t a measure of how well someone documented what someone else said.  The quality point SHOULD BE on the accuracy and precision of the statement made.  In other words, the value of the requirement statement is realized ONLY by its validity.  What is commonly overlooked is the credibility of the person communicating the statement of need.  In other words, far too often, the credibility of the so-called Subject Matter Expert (SME) is taken for granted.  Rarely does the typical business analyst make any effort to verify the expertise of the SME.  This lack of a “check and balance” or verification/validation of the SME’s range, depth, and accuracy of knowledge (much less performance skill and experience) is a gross error that points to the ROOT CAUSE of most software development failures, disappointments, and budget busts.

In reality, a named SME is usually only the most knowledgeable person (about a process) in the organization.  To declare this person an “expert,” without any form of validation or verification of their expertise is imprudent and risky.  In other words, stop taking the SME’s word for it.  Instead, start focusing on verifying the details of the process.  That effort qualifies the expertise of the SME.

The diagram below illustrates the concept of the thesis of this blog and my previous three posts.  In Step 1, you see a BPMN diagram of the entire process, “Receive, Record, and Initially Respond to a Request for Service.”  In Step 2 a data flow task is isolated.  In this case, the task shows a need (or requirement of the process) to update a customer record.  Step 3 is the statement of the requirement.  The concept behind this simple illustration can be applied across the entire spectrum of software requirements.  With regard to the functional requirements of software, if a requirement can’t be traced to a data flow (create/read/update/delete) task, then what would its origin be?

The Need(s) of the PROCESS drives the Requirement(s) of the Software