The #1 Key to Project Success

THE #1 KEY TO PROJECT SUCCESS

In this inaugural blog post for Radgiver Services, I'm going start out discussing the most important thing for any project. Be it a full system implementation or a small process improvement project, the single most critical thing to allow success is…requirements. These are the guideposts, the markers. They are the success criteria if met. Requirements are the fences within which every project operates when making decisions on knowing not only when it's done...but how it should even start.

What are these requirements then? They come in three forms. Statutory and Legal. Corporate policies. Suggestions. The first set is pretty obvious. Statutory and Legal requirements take the shape of items that are simply not optional. Reporting Sales Taxes, meeting FDA labeling requirements, passing ITAR compliance, that sort of thing. Every project simply has to keep these in mind and make sure they are covered. Policies are the next most important. Safety goals, Employee work hours, expense reporting standards, and Non-Disclosure are examples of formal, written policies that govern how a company will operate. These Policies can also take the shape of stated corporate goals, those things that have been communicated to shareholders about how the company operates. That leaves what I loving call 'suggestions'.

Why do I call them suggestions? Well, if they aren't company policy…and they aren't legal in nature, then that's essentially what they are. Nobody is going to jail if they aren't followed…and they are far easier to change than true Policies. These kinds of requirements are always the most important to a project's future success. It's relatively easy to build a process or design a system around something as truly set in stone as that which is proscribed by the Department of Defense or something that is in the employee handbook everyone gets day 1. But those other requirements? Suggestions? Those are the desires of the current CFO, the new plan from the latest process guru, or simply the way things have always been done because some user or other only knows one way. Separating out REAL requirements then from those that are truly just suggestions is pretty key.

How do we sort through these suggestions to get to real requirements. Requirements can be literally defined and measured. Requirements shouldn't be optional. Requirements are the ways the business will judge itself. Does every invoice have to be printed and hard-copy stored? Not have to? Then it's not a requirement. Does every shipment have to be signed off as inspected? Has to (for whatever reason)? Then it's a requirement. Almost always, common sense can be used to review, discuss, and decide if something is a requirement for a project.

So how can these suggestions then be used as an input to a project? Well, that's fairly straightforward as well. Define them in specificity and get buy-in/sign-off that they are required to be considered in the project definition. By specifically defining them into measurable, meaningful direction we can clarify the intent and impact. By forcing sign-off, we build accountability. Accountability, another of the keys to success, means that management signs off on the idea that the project direction has now been written. Now a longer, more complex project may result. A less-than-optimal outcome in other areas (those not tied to requirements) may be forced. But that's what requirements do, they drive the project to meet specific objectives.

Let's look at some examples of these 'suggested' requirements and their potential impacts.

• One database instance for multiple legal entities in different countries

  • Lower system maintenance costs

  • Perhaps no good time to take the system down for that maintenance

  • If some data is 'common', it may be difficult to agree on what to use

• All Parts will be Lot tracked

  • Lot tracking lends itself to many obvious gains for managing recalls and controls

  • Warehouse management may be forced to be more selective in location usage

  • Production will potentially be measurably slower as every lot is checked in consumption

• Change Orders will be used by Purchasing for all changes to approved POs

  • This leads to good control and review standards

  • Timing can greatly be impacted, even for the smallest change, when timing may be key

  • If all Orders require Changes, they may not get the same review as they would if Changes were more the exception

As we can see, requirements drive specific decisions on process and systems configurations. They can lead to positive outcomes, but can have negative impacts on other areas. But if they are truly requirements then those impacts have to be borne. By clarifying what are true requirements, and what aren't, a project can focus on specific goals.

A recap. When building out the requirements for any project, it's important to understand all of them. Legal, Statutory and Policy requirements have to be included. But filtering through and turning those others, those suggestions, into usable requirements…that may be the most important task of all. For a project to succeed, the project must clarify and document all types of requirements.