Articles

Have you ever wished you had a short checklist of things to keep in mind as you manage projects? Would this short list contain key measures that, when kept in check, would lead to project success?

In addition to following industry guidelines, it's vital to keep these key measures top of mind throughout the whole project - from start to finish. In the rush to get a project underway, these factors can be overlooked or forgotten. 

In order to help you achieve your goals, here is a list of 4 key measures:

1 - Make sure you know these things before starting a project or even looking at business requirements:

Get in touch with the executive sponsor and ask for the following information:

• Intentions and scope of the project
• Out of scope and what the project is 'not'
• There must be a clear understanding of who the "Customers" of the project are (internal or external customers)
• What is expected in terms of Return on Investment. Does the ROI document exist? Where are returns expected in the business?
• Budgeting and approval of expenditures
• A list of expected success factors for the project
• The project should move forward at the present time, if not, when will it begin
• Project completion timeline 
• The agreement to dedicate company resources to the project
• Status and reporting requirements for the project
• Agreement on how to communicate plan to sponsors, customers and other impacted parties
• The sponsor agrees to assist in resolving any difficulties with the project that require his or her attention.

This information should then be put in writing, usually in a project initiation document, which should be signed by all the project leaders, sponsors, customers, and the CIO. There are many times we have come to the end of a project and at least one of these parties (sponsors, customers, or CIO) claim they never agreed to some portion of the documentation in the project initiation document.

This is especially important for System Implementation projects since it may take a long time to complete the project and deliver the final product.

2 - Business Requirements

Take the time to properly document all business requirements from all customers before talking to any IT personnel (if it is a system implementation), or product vendors. In order to document business requirements, you should at least follow these steps:

• Identification of the subject matter experts and project representatives from each part of the business who will be the ultimate customers, and that includes:
  • Determine the current problem or need
  • Document current processes
  • Discuss what is not working about the process
  • Identify the results they would like to see  

• It is not a good idea to discuss what systems or technologies will allow them to do in business requirements documentation. Rather than doing that, focus on what the business needs. Avoid allowing your customers to define processes based on technology or systems. Business is supported by technology, not dictated by it. Eventually, everything will fall into place.
• All business requirements discussed with all customer groups and subject matter experts should be documented. It is important to specify the problems and needs, how it affects the business, what is needed, and how it will help the business. Be as specific as you can! As a result, you will be able to put together the ROI document and ensure that the expected cost and benefits are in line with what the sponsor(s) is expecting. Some project managers might disagree here and state that the ROI should be done before getting to the business requirements stage. Going through the business requirements discovery process always reveals new investment opportunities (costs) and returns.
• Always consider how a product will be used and how reporting will be required. If you don't pay close attention during the requirements phase, it can really hurt you in the end.
• In the project initiation document, you created the scope for the project. If the scope changes, you will have to amend the initiation document with new signatures.
• As soon as the right set of requirements is documented and aligned with the project scope, make sure project sponsors, customers (remember, customers can be internally or external), and CIO acknowledge that these are the business requirements, the project is active and sponsored, and they agree with moving forward with the next steps. People tend to forget or say things like "I never said that" as the project progresses. If that happens, the original documentation and signatures can always be referred to. 

3- The next step is to determine how you will fulfill these requirements.

In most cases, this leads to a decision to buy or build. That is, buy software from a vendor that specializes in the type of product needed, or build with internal IT personnel. The business requirements document is the basis for evaluating whether you should buy or build.

       Select your vendor(s): 

• When you are "buying" a software product from a vendor, begin by "paring down" the top software products based on the business needs. Keep within the scope; do not go off course without getting the approval of the team.
• Once you have your top list of software contenders, have the vendors perform demonstrations for your customer group(s). Their vote can be counted as part of the selection process. Getting your customers' buy-in is crucial at every step.
• Ideally, you should run a trial phase with two top vendors to see how the business requirements match the product.
• As soon as you have completed the trial phase, get back to your customers to demonstrate the products against their business requirements. Thenhave your customers make their final selection. 

       Build your own solution: 

• Make sure you have consulted your sponsors, customers, and CIO or other representative IT parties before beginning a major development phase to ensure that the specifications and agreement for moving forward are agreed upon.  A new project schedule outlining the full development schedule, resource requirements, and commitment from all parties involved will also be required during this phase.
• As soon as the business requirements are defined, a technical specification document should be written to match them. This document describes how business requirements will be met in the product, what requirements cannot be met or can only be partially met, and what IT requirements are required.
• Throughout the development process, do a "pulse check" with your sponsors and customers. Thisensures your customers are not surprised by the result or that you have not taken a wrong turn or developed something incorrectly. Your customers and sponsors will have a higher perception of your project's success if you catch these issues during development. Overall, it's better not to have any “hang-ups” during the development process, but it's probably not realistic to expect there won't be any. As a project manager, you're responsible for working through such challenges and completing the project on time. 

4- Change Management shouldn't be overlooked!

During the implementation or development phase, document how the solution impacts business processes. The new process will need to be discussed with customer group representatives, and the document describing the impacts should be in place and agreed upon with customer group representatives prior to any solution rollout.  

If you do this, you can expect a much smoother training and rollout phase of the product than if you just try to throw the final product out there. If you do not have a carefully planned training and rollout phase, all your work will go down the drain, and the project will most likely not be perceived as a great success.

Additionally, it is extremely important to communicate what users need to do if they need assistance with the product during the rollout and training phase. What kind of support is available for this solution/product?  During the rollout and training phase, a good project manager will already have this in place and ready to go. Also, make sure the customer groups agree on the support process and think it will work for them.  

The last thing you should do is follow-up with customer groups to make sure they are running smoothly and that any problems or issues that need to be addressed have been resolved. As long as your customers are happy with the final product, you should continue to do so.