Defining Implementation Success or Failure

Sometimes indentifying whether your project or implementation was a success or failure is not as straightforward as just looking at the metrics involved with project management. It’s not always about on time and on budget. And it may not entirely be about customer satisfaction either.

In Henry Lucas’ book “Information Technology for Management” he defines first what an Implementation is and then looks at some of the possible criteria for determing that implementation’s relative success or failure factors.

What Is Implementation?

Implementation is part of the process of designing a system and is a component of change. We develop a new information system to change existing information processing procedures and often to change the organization itself. Implementation refers to the design team’s strategy and actions for seeing that a system is successful and makes a contribution to the organization.

Our definition stresses the long-term nature of implementation. It is part of a process that begins with the very first idea for a system and the changes it will bring. Implementation terminates when the system is successfully integrated withthe operations of the organization. We expect most of implementation to be concerned with behavioral phenomena since people are expected to change their information processing activities. Implementation becomes more important and difficult as systems design becomes more radical. If a firm undertakes a maj or reengineering project, it should make major changes in tasks to reduce costs and improve productivity in the organization.

Success or Failure

How do we know that we have successfully implemented a system? Researchers do not agree on an absolute indicator for successful implementation. One appealing approach is a cost/benefit study. In this evaluation, one totals the costs of developing a system and compares them with the dollar benefits resulting from the system.

In theory, this sounds like a good indicator of success, but in practice it is difficult to provide meaningful estimates. Obtaining the cost side of the ratio is not too much of a problem if adequate records are kept during system development. However, an evaluation of the benefits of an information system has eluded most analysts. There are a number of categories into which we might classify the benefits or value provided by an application of technology. These categories include:

• Infrastructure
• Required applications
• Applications where technology was the only solution
• Applications providing a direct return
• Applications with indirect returns
• Technology initiatives that are a competitive necessity
• Strategic applications
• Transformational information technology

For only a few of these categories are we likely to be able to demonstrate a direct financial return, which makes it difficult to perform a cost/benefit analysis to determine the “success” of a system.

As an alternative, we can choose among several indicators of successful implementation for an individual application, depending on the type of system involved. In many instances, use of a system is voluntary. A manager or other user receives a report but does not have to use the information on it or even read the report. Systems that provide interactive retrieval of information from a database also can often be classified as voluntary. The use of such a system is frequently at the discretion of the user. A manager with a personal computer in his or her office is not required to use it. For the type of system in which use is voluntary, we shall adopt high levels of use as a sign of successful implementation. We can measure use by interviews with users, through questionnaires, or in some instances, by building a monitor into the system to record actual use.

For systems whose use is mandatory, such as a production control system or a computer that provides stock market quotations for a broker, we shall employ the user’s evaluation of the system as a measure of success. For example, onecan examine user satisfaction, although it will probably be necessary to measure several facets of satisfaction, such as quality of service, timeliness and accuracy of information, and quality of the schedule for operations. An evaluation might also involve a panel of information processing experts reviewing the design and operation of the system. We should also note that managers might well consider a system to be successful if it accomplishes its objectives. However, to accomplish its objectives, a system must be used. We would also hope that one objective of a system would be extensive use and a high degree of user satisfaction.

Finally, though it is difficult to do, we can try to estimate the impact of a system on individuals and the organization. How has a system affected personal productivity and output quality? Can the organization point to added sales or increased revenues from a competitive application? Can we show that IT has had an impact on performance, either for individuals or the organization?

The Project Change Order Request – Version 1

Ah…the Project Manager’s best friend and worst enemy…the Change Order Request.  Projects have been halted and customers have been lost by presenting one of these fun documents.  As most of you aware, the change order request is created to cover a known gap between the work that must be done and the work that was planned (and usually priced).

The change request originates because the customer or project now needs something that wasn’t planned as part of the original project scope.  It usually comes with a price tag because of a change in the customer requirements.  However, it can be and should be used to document any deviation in scope – even if it doesn’t result in a price change for the project.  That way you have a baseline (the original SOW and requirements) for the project and documented changes to that baseline (the change request documents) as a paper trail to cover what work was actually performed on the project.  It can also be useful at the end of the project when you’re trying to justify the resource hours spent on the engagement.

I’m calling this one Version 1 because I have at least one more example that I plan to post soon.  Email me if you find this helpful and would like a Word doc version of it or send me your example to post if you want to share a different version to our readers.

PROJECT CHANGE ORDER REQUEST

[Save file name as: client name CHANGE ORDER yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

ISSUE TO BE ADDRESSED:

Describe the issue which the scope change will address

PROPOSED CHANGE IN SCOPE:

Describe the details of the scope change.

BENEFIT OF THE CHANGE IN SCOPE:

Describe the results of the scope change.

COST IMPACT OF THE CHANGE IN SCOPE:

The additional cost for this change will be $0. This will bring the total project cost to $0.

SCHEDULE IMPACT OF THE CHANGE IN SCOPE:

Project Schedule will be modified to a project completion date of month dd, yyyy.

ACCEPTANCE OR REJECTION OF THIS CHANGE ORDER:

The Client must accept or reject this Change Order within THREE (3) days of the date of this Change Order. The client’s failure to accept or reject within the prescribed period of time shall be deemed to be a rejection of this change order and Vendor shall continue with the project as if no change order had been issued.

Client hereby: Vendor hereby:

______ ACCEPTS the Change Order.

______ REJECTS the Change Order.

________________________________

Client Signature

______ ACCEPTS the Change Order.

______ REJECTS the Change Order.

________________________________

Vendor Signature

The Business Case Document

I’m trying to get on a roll providing our readers with some hopefully meaningful samples and templates of documents that may be needed on their projects.  These are templates that I created a few years ago – basically from information I think I probably found somewhere else…(isn’t that always the case?).

As I stated in The Project Charter Document article, if our readers have samples or templates they’d like to share, I’ll be more than happy to provide alternate versions of documents that I’m including here or examples of documents that I’m not covering…either will be much appreciated.  And I’m also very willing to send along Word doc versions of these templates to anyone who asks…just email me.

Here I am presenting a template for a Business Case Document.  If your customer is external, you may never see this or may never be involved with it.  If your customer is internal, it’s very possible that you’ll not only see it, you’ll be asked to help create it.  The key is to try to justify the existence of the project and the work to be performed.  The best way to do that is to show some cost/benefit analysis or return on investment (ROI).

This doesn’t have to be an extremely detailed document – leave that for the statement of work (SOW) and, of course, for requirements documents.  It does, however, need to speak very well to executive management and the key decision makers if there is to be any hope of kicking the project off.  Someone, somewhere, makes the final decision on whether or not to throw $$ and personnel resources at this effort and this document needs to convince them to approve that effort.

PROJECT BUSINESS CASE

[Save file name as: client name BUSINESS CASE yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

SOLUTION

Describe the proposed solution.

COST MODEL

ROI SUMMARY

Describe when the break-even point of the project will occur and expected annual revenue generated by the project.

PROJECT RISKS

Describe risks that may impact the cost/benefit of the project performance.

Leading and Following in a Hierarchical Organization

I’m a fan of the show Criminal Minds. Very intense, very intriguing, slightly disturbing. Recently, due to a situation with a very personal case, Thomas Gibson’s character Hotchner, had to relinquish leadership of the FBI Behavioral Analysis Unit (BAU) to another character, Morgan. In preparation for this, Hotch started to give Morgan some paperwork-type tasks that Morgan felt was menial. Morgan thought he was being punished when, in fact – as he would later find out – he was just being prepped for his new role. Those paperwork items were things Hotch always had to do, but no one else knew about because he ‘just did them.’

Just Say NO to Busy Work

Leadership of any kind comes with costs. What all organizations must do is understand how much of that extra ‘paperwork’ is really necessary for those that they are asking to lead. Busy work should never – repeat NEVER – be required of a project manager, or any leader for that matter. In fact, many organizations ask that their successful project managers operate with little to no direction and give them quite a bit of autonomy in their jobs. If there’s a PMO in place, then a once per week meeting with all the PMs as a group to go through any company news and specific project-related issues should be sufficient.

Everyone Benefits from Standardized Reporting

The idea is that your PMO processes and your project management policies already in place will mean that you have a somewhat standardized status reporting process already. And those standard reports should be sufficient information for the PMO Director to see without requiring tedious other reporting information or mechanisms. I believe that a PMO Director should be always trying to clear paths to success for his or her project managers.

Never should they be requiring project managers to create extra reports in different formats to satisfy their own reporting needs. Figure out a standard report on project status that fits all needs and ask that PMs use that as a general template as they move forward in their projects…then just have the PMs cc the status report to the PMO Director every week as they deliver them to the team and the customer.

I’ve been a part of organizations and PMOs that seemed to want to load down employees with meaningless paperwork and reports. Micro-management has no place in organizations I work for…it drives me crazy. That’s probably why – self-admittedly – I’m sometimes not the best person to have as an employee. I’m an independent thinker and hate doing things that get in the way of doing what is right for the project…meaning what is best going to serve the project, my organization and my customer. Am I stubborn…yes. But I also feel that stubbornness and independent thinking are two very critical characteristics organizations should be looking for in their project managers.

Summary

With all this rambling, what exactly am I trying to say? Basically that project managers who are part of an organization – either in a formal PMO or distributed throughout the company – are always asked to lead and often asked to follow (such as with a PMO Director). We’re responsible for a lot – sometimes it seems like the world – as project managers as we try to satisfy the customer, our team, and our company leadership.

The key for the PM is to be a good leader and a wise and efficient follower. Do what is expected, but protect your team, your project and your customer. Therefore, if you’re seeing processes that do not make sense…question them. But when you do question them, also come with a proposed solution. Think proactively. Processes within organizations seem to cycle through significant changes every 2-3 years. Be a change agent for efficient processes within your company…everyone will benefit.

Ten Guidelines for Managing Passwords in the Enterprise

As a follow-up to my article entitled “The Most Serious Data Threat May be Sitting Next to You,” Mark Sanford from Click Studios sent me a link to their article on “10 Guidelines for Managing Passwords in the Enterprise.” Since data security and data integrity is a critical issue on any enterprise IT project that involves significant data – and they all do – this is extremely timely and appropriate.

Mark and Click Studios have graciously allowed for their article to be provided to the readers of PM Tips. I strongly urge you to also visit their site and the original article here.

10 Guidelines for Managing Passwords in the Enterprise

Today the world is totally dependent on information technology, and many corporations struggle to effectively manage and store passwords securely for their employees. Every other day you hear of large companies exposing customer account details to non-intended audiences, due mainly to poorly managed IT systems and processes. The confidentiality and integrity of sensitive data is paramount to the operations of any size business, and the following guidelines should be considered when choosing any type of electronic password management system (PMS).

1. Remove the need for employees to remember passwords, or even worse, write them down

A key cause of bad password management practices is many employees don’t have a system in which to records their passwords, resulting in them having to either remember them, or write them down and store them in an unsecure manner. The password management system (PMS) must provide adequate functionality, removing the need for employees to remember passwords.

2. Centralize the management of passwords

Centralization of an organization’s passwords is the first step in gaining control of the IT accounts used to operate their business, otherwise there is no visibility or governance of their usage.

3. Ensuring the integrity of sensitive data

To ensure the integrity of data stored in an electronic PMS, there are a few key things to consider:

• Passwords should be encrypted with 256bit AES encryption, and a unique Initialization Vector used for every install
• Users should authenticate against the PMS using their Microsoft Windows domain account credentials
• PMS must provide the option to use two-factor authentication for the user(s) who administer the system
• Sensitive code of the PMS should be obfuscated, to prevent reverse engineering by system or web administrators
• PMS must mitigated against system or database administrators granting themselves access to unauthorized data

4. Make the passwords easily accessible

Users must be able to get to the PMS from any location, must not rely on any client installs, and must give them quick and easy access to their passwords.

5. Must promote the use of strong passwords

The PMS must promote the use of strong passwords, of which the policy for password strength is set by the administrator(s) of the system. Visual representation of password strength must be available when entering passwords, or when reporting against, so the user is constantly reminded if a password’s strength is poor.

6. Must promote regular resetting of passwords

A key component of bad password management practices is not resetting passwords at regular intervals. The PMS must have one or more options for reminding users that passwords are about to expire.

7. Must be portable and recoverable

There is little use centralizing your organization passwords if you’re unable to get to them in case of a disaster. The PMS must provide the mechanism by which all passwords can be exported to a separate file, to be stored outside of existing IT systems – preferable with trusted security personnel.

8. Changes must be traceable and auditable

All large organizations require governance over access to IT systems, and its imperative the PMS must support traceability of all events within it, and must be easily reportable. This applies to standard usage by employees, or administration of the PMS.

9. Must be scalable

If you intend to implement an enterprise class PMS, its crucial the system can scale with your organization, otherwise your investment (time and money) may be wasted.

10. Must be simple to use

As with any IT system, acceptance by its audience is crucial to its success. Provide users with a poorly designed interface, and you will meet resistance at every step. To successfully employ a PMS and realize the benefits it can bring, the PMS must be very simple to use and provide the user community with sound help documentation if required.

(Click Studios – 18^th October 2009)