Why keep up with technology?

Executive Reality Check (Part 3)

Bottom line up front: Are you leading or lagging in your technology adoption? For fifty years, new technology has evolved every 18 months (Gordon Moore’s “Law”). How old is your technology?

Executives, here is your third reality check for 2017.

REQUEST: Consider these technology issues

  1. The Internet of Things (IoT) is forcing CEOs to rapidly adapt their IT business plans. 26 billion devices will be connected to the Internet by 2020. Do you need to change your business plan?
    • Does your company have an IoT strategy?
    • Does your competition have an IoT strategy?
  2. Internet digital disruptions are changing B2B and B2C sales models; and, Gartner says within 10 years, all sales models may look radically different. How nimble is your sales model?
    • How is your company addressing / embracing digital sales disruptions?
    • How is your competition managing digital sales disruptions?
  3. Ultimately, customer experiences drive all business performances and that drives all revenue growth.
    • What would your customers report about their experience with your company?
    • What would your customers report about their experiences with your competition?

DECISION: If you found any of your answers lacking to these questions, then what are you going to do about it?

ACTION: Assess your technology upgrade and replacement plans! Judge how ready you are for fully embracing the Internet of Things. Reaching out to supply chain experts for technology help is a strategy that works!

Here is a technology analogy to consider: From 1950 through 1992, the station wagon was the technology to drive if you had a growing family. Then, from 1992 to 2008, the mini-van reigned supreme. And, while versions of mini-vans have been recently reincarnated, SUVs are the modern conveyance for families. While all models were state of the art in their time, safety and innovative technology advancements have changed with each car type and no one would seriously consider driving older technology today.

Do you change cars more often than you change your business technology? 

Mitigating risk is the hardest of jobs

Executive Reality Check (Part 2)

Three more questions for executives to consider. These are perhaps even more important. How much risk can you and your company handle?

Executives, here is your second reality check for 2017.

REQUEST: Consider these business risk issues

  1. Suppliers have risks: financial, operational, and compliance – and each one can impact your supply chain performance and your revenues.
    • How do you mitigate risks for your business critical categories?
    • What is your plan for business and economic uncertainty, and how do you forecast for it?
  2. Disasters can and do happen. Surveys indicate operational problems (power loss, communications loss, etc.) are the largest causes of disasters at 45%, followed by natural disasters at 35%, and human error at 19%. Recovering from any disaster can be risky, time-consuming, and expensive. Many companies never recover.
    • Is your business continuance / disaster recovery (BC/DR) plan up-to-date with your current business model?
    • Does part of  your business software infrastructure operate in the Cloud? Why not?
  3. Supply chain collaboration and product visibility is crucial to reduce business risks in a timely fashion.
    • Do you utilize supplier or customer portals to receive / place orders?
    • Can you automatically track product movements or product shipments, and make adjustments?

DECISION: If you found any of your answers lacking to these questions, then what are you going to do about it?

ACTION: Prepping and rehearsing BC/DR strategies annually requires a total corporate commitment and a formal action plan. Reaching out to supply chain experts for help is a risk mitigation strategy that works. Address your BC/DR shortfalls and hope that you don’t have to use them very often!

Many executives have sleepless nights worrying about how to mitigate risks for their companies. And, if your products have the potential to face recalls that may have caused injury or death, your risk issues multiply. Plan accordingly!

Executives are busy. Who isn’t?

Executive Reality Check (Part 1)

Being a corporate executive means one has a corporate responsibility. And, even busy corporate executives need to stop and take a business reality check from time to time.

Executives, here is your first reality check of 2017.

REQUEST: Consider these business critical questions

  1. How does your company measure progress?
    • Are your business performance metrics meaningful and timely?
    • Are you leading or lagging your competition? How would you know?
  2. How well does your supply chain software perform?
    • Is your supply chain software more than five years old?
    • Is it time to replace or retire your software model? How do you really know?
  3. Business models change daily. Does your supply chain software keep pace?
    • Is your supply chain software encouraging or constraining growth?
    • When did you last perform a supply chain software review?

DECISION: If you found any of your answers lacking to these questions, then what are you going to do about it?

ACTION: Hoping issues will soon go away is not much of a business strategy. Reaching out to supply chain experts for help is a business strategy that works. Address your shortfalls and re-prioritize your business goals.

Time is money, accordingly to Benjamin Franklin. What are you waiting for? How much are you willing to lose before you invest in a change?

First Drones, now a Flying Warehouse

Mobile Distribution Centers

When I first heard of Amazon delivery drones, I assumed they would have to fly bi-directionally from a stationary, land-based distribution center. Lots of logistical issues to overcome with that concept, I thought.

Now I learn that Amazon has been really creative; and, that I was totally wrong in my conception. Amazon’s idea: why not use a  mobile-based distribution center that can be moved anywhere – on-demand?

This staggering novel concept completely turns the notion of delivery system models upside down; and, it re-imagines what supply chains in the future could look like.


Amazon was awarded a patent in April 2016 for the concept (diagram above) of deploying a mobile-based flying warehouse or an “airborne fulfillment center” (AFC). This information was recently uncovered and distributed by CNBC last week.

Imagine a customer order triggering a drone, or unmanned aerial vehicle, to fly down from a high-flying AFC to fulfill immediately their order. Then, not to waste any space or opportunity, one interesting aspect of the patent is that the airship itself could be used as a giant advertising board, alerting customers of special items on-board. Imagine if the Goodyear Blimp could deliver tires directly to your car or home.

Conceptual Usage

CNBC reported on an example of a sporting event where specific team items could be pre-loaded in the AFC allowing pertinent items to be ordered and delivered to consumers within minutes, perhaps directly to one’s seat in the stands.

How about envisioning a scenario where the Kansas City Royals win the MLB American League Championship game (again) and celebratory league championship t-shirts can be delivered to ecstatic fans minutes after the game is over. Crazy? Yes! Unbelievable? No, not anymore!

This AFC idea takes the concept of a “pop-up” temporary store to a whole new (and higher) level.

The realization of such a distribution/delivery concept would be a game-changer to many supply chains, especially retail related.

Here are a few question to consider:

  • How could your company utilize airborne fulfillment centers?
  • Who will do it first? You or your competition?


Executive Planner: Software Projects (Part 6 of 6)


Step Six

Identify risks if project goals and deadlines are missed

“What If” Risk Assessments

The more significant and important a software project might be for a company, the more time should be spent on identifying and assessing its associated risks.

The risk assessment questions to be explored might be: What happens if the decision to begin the project is put-off? What happens if the project start date is delayed? What happens if the project goes over budget? What happens if a go-live target date is missed? What happens if there is project scope creep? What happens if the project is cancelled? What happens if key members of the project team leave or are reassigned? What happens if the project’s goals are met early resulting in sooner than expected business changes?

For each of these questions, one may need to consider both the positive and negative risk impacts of (1) any changes to a company’s financial plans or fiscal budget; (2) any changes to other internal operational initiatives or programs; (3) any changes to mandates imposed by strategic business partners, or by regulatory agencies; and, (4) any overall changes felt by exceeding, meeting, or ignoring competitive market pressures.

The Decision Risk of Now vs. Later

For complex and/or perceived expensive software projects, companies sometimes struggle with making a business decision to move forward, or even when to start a project. The term “paralysis by analysis” is commonly used in these situations. This may be understandable since everyone wants to make a correct and affordable decision for the right business reasons; but, sometimes specific answers, or a project’s impact on business, may not be fully understood, appreciated, or known until one gets deep into the discovery, design, and integration planning aspects of a project. So, how does one decide when and what to do next?

As is often stated, the only true business constant is change. And, business change is always inevitable. One may ask then, how long can inevitable change be put off? Can legitimate business risks and costs be better mitigated and managed today, or could they be put off until tomorrow? Is there a balance point in between? The real business decision factor may come down to a discussion on moving forward now or moving forward later. Companies, with similar project needs and requirements, may follow completely different paths and make completely different decisions, all for equally valid reasons.

One critical financial consideration, worthy of closer examination in decision discussions, concerns the real impact of a project’s calculated return on investment (ROI). As previously noted, ROI is often expressed in terms of time; and, it can be calculated as a monthly savings figure. It is important to factor in decision discussions that for every month that a project decision is put off, delayed, or deferred, the calculated monthly ROI savings figure will forever be lost, never to be attained or re-captured.

To illustrate the financial ramifications, suppose a calculated monthly ROI saving figure is $15,000. A project decision delay, or a project start pushed out six months into the future would mean that an estimated savings of $90,000 would be lost forever (6 x $15,000 = $90,000). For many companies, this potential ROI savings figure could represent a significant financial number that is difficult to ignore; and, the larger the project might be, the larger the potential ROI saving that could be lost.

Accordingly, for many companies, finding the quickest path forward to enable ROI savings can become a primary motivating factor to start a business project sooner rather than later.


To download all six steps, click the link below:



Executive Planner: Software Projects (Part 5 of 6)


Step Five

Establish reporting guidelines and change processes


Executives tell me that a project manager’s most critical job function may be project communications that need to be managed in a timely manner; and, one cannot over emphasize its importance to a project team or the company.

Much like a juggler with multiple balls in the air, a project manager must keep team members, and project stakeholders, in the loop on where a project stands with tasks that have been completed, where the project is on its timeline, and how funds are being spent.

If there are project problems to be addressed, then the entire team and stakeholders should be aware of all issues. And, as milestones are met, the entire team should celebrate in their team’s success.

There is a balance to be found between “quantity” of reports and “quality” of reports when trying to establish a reasonable project reporting standard. Most project managers find that weekly reports are more than sufficient for their team. However, when a project approaches certain targeted milestones, more frequent reporting may be necessary. This may be especially true in complex projects with a larger team, or with projects having multiple milestones being tracked and attained simultaneously, or with companies engaged at multiple physical sites.

There is a growing trend for project managers to use electronic project reporting and tracking tools such as Microsoft Project™, or a similar program. Additionally, I find that many companies have made excellent use of dedicated SharePoint™ sites that contain all project related information. I highly endorse the usage of these techniques to provide real-time information and project status updates on-demand.

The Nature of Options

The general nature of all ERP software projects is to explore options that will provide the best case business scenario for a company to move forward.

Executive sponsors, project teams, and project managers commonly learn that there may be multiple ways to achieve the same programmatic outcome. Figuring out which way works best for one’s company may be the fun part of a project’s design and development phases.

Additionally, teams and managers may discover that some business processes work differently in practice than they do in theory. And, just because one way is specified in a project’s blueprint, it does not mean that other options cannot or should not be explored, too. Accept in advance that blueprints will likely change and evolve over time as project teams become better at probing, exploring, and understanding the options presented.

Tracking Changes

Sometimes requested changes to a project are minor and will have little, if any, impact on the total project budget. However, sometimes, requested project changes can be significant and costly; and, in those cases, there could be a significant impact to a project’s budget, staffing, and timeline.

A project manager should formally track and document all requested project changes, including the ones not accepted or approved. The project manager is also responsible for managing the decision process to gain the executive sponsor’s buy-in that a proposed change is valid, accepted, and formally approved.

Tracking and recording change requests, and their approval/cost/validation processes, are necessary strategic steps for the overall project goal of not having surprises at the end. In my experience, having a well-documented audit trail for every project change request can be worth the effort. And, if one’s company has ISO aspirations, or legal regulatory compliance issues, then a documented decision audit trail can be very beneficial for other business reasons.

Executive Planner: Software Projects (Part 4 of 6)


Step Four

Create a budget and set an ROI target goal

Estimating Cost vs. Actual Cost

Two common executive questions I hear are: (1) what will be the software project’s cost? And, (2) how quickly will there be a return on the investment? These are very specific questions. To provide specific and accurate answers, these questions require an in-depth review. And, there will likely be a considerable time investment to discover and to uncover specific needs, to establish and prioritize goals, and to set project budgets.

However, for some software project discussions, this level of work detail may be like putting the cart before the horse. A potential software project may first need to navigate through an internal vetting process before it can be included in a formal budgeting discussion; and, perhaps, for vetting purposes, only a general idea of project costs may be necessary.

Based upon my experiences, what executives may be really seeking is the answer to this general type of business planning scenario: What might be the “typical” cost range and time required for a similar sized project to ours, so we can plan for its impact on the rest of our company’s budget; help estimate the required resources needed; and, to project IT staffing needs? And, then, based upon these general estimates, maybe we can determine if the project is affordable, or cost justifiable so it can move forward to a formal budget process. Whew! Does this broad scenario seem familiar? I hear it often.

There is an inherent difficulty with trying to address “what if” planning scenarios like the one above. Questions can be really awkward to answer, and often answers are inaccurate because, as noted earlier, no two projects have the same blueprint or the exact same complexity. In reality, there is no such thing as a “typical” project. Each one is unique.

Complexity and Project Duration

I can definitively say that a project’s complexity will correlate directly to both time requirements and to budget costs. For planning and vetting discussions, one can make a few educated assumptions by using the chart below to guesstimate a project.

To visually illustrate complexity, the graph shows three different ERP software project types: an upgrade, a migration, and a new implementation. Note that each project type offers different examples of complexity: low, medium, and high. At a glance, as one might expect, an ERP version upgrade in an existing environment should take considerably less time and cost less than a completely new and highly complex ERP implementation.



* Other commonly included modules may be Human Capital Management (HCM), Customer Relationship Management (CRM), Payroll, Supply Chain Management (SCM), and Business Analytics (BI)

Additional time may be required for specific third-party program integrations, personalization, data migration, and custom software development

Project cost range examples are conservative; and, actual results may vary due to other factors

Chart Usage Assumptions and Directions

If one’s project only pertains to financials, then use just the purple portion of a bar as a reference point. If one’s project has financials and distribution, then add the purple and dark blue bars together, and so forth to approximate a project’s duration. Then, align the project to its estimated low, medium, or high complexity bars. By combining or subtracting the colored software application segment bars on a line, one may be able to build an approximate idea for a software project timeline and a budget cost range estimate.

Actual cost results may vary significantly due to unknown factors. Please realize that true project costs and ROI cannot be fully identified without an in-depth discovery effort.

Cost Justification

The justification for a software project may be measured with tangible metrics with easily identifiable savings generated by a reduction in errors, or in improvements to labor efficiency. However, the justification could also be measured with intangible savings like reductions in customer service calls, or fewer warranty repairs. And, there are times when the justification may be measured by reducing corporate risk and legal exposure due to previous product recall liabilities. Finally, sometimes justification reflects various degrees of all of the above for one’s own business reasons. All cost justification techniques may be equally valid.

Every company has their own financial preferences and formulas used for cost justifying a project. Companies can utilize an internal rate of return (IRR) formula, a project’s net present value (NPV) formula, or calculate the payback in terms of time (it will take “x” number of business months/days in savings to pay back the investment spent).

Additionally, one’s accounting department may have their own return-on-investment (ROI) measurement standards for projects, such as if the project expenditure is less than $500K, then the ROI goal should be within 24 months; or, if the project’s expenditure is less than $1M, then the ROI goal should be within 36 months. Or, it may be that an IRR goal should be 20%; or, that an NPV goal should be 15%. Every company sets their own financial ROI goals and targets to be attained.

A budgeted software project and its ROI are often viewed as two sides of the same coin. For ERP projects, there is nearly always a positive operational payback, and a financial ROI that will be attained. The variable may be in how quickly the ROI will be reached and surpassed.

%d bloggers like this: