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:

software-project-planning-guide-by-jerry-horne

 

Step Five

Establish reporting guidelines and change processes

Reporting

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.

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.