Project Transition to Production Support

As part of methodologies I’ve previously discussed, the final phase is something that I call the Post-Deployment phase.  Once the project is implemented – or deployed – the delivery team, the customer, and the project moves on into the Post-Deployment Phase.

The Post-Deployment Phase is the period of time when the delivery team remains as intact as possible to support the customer and the deployed solution before a final and formal transition to technical, or production support.  This post-deployment period is usually somewhere between 30 and 90 days in length (30 is more likely) and that time period is set either during the sales process (and becomes part of the statement of work) or during the kickoff session.

Upon satisfaction of the post-deployment timeframe, support formally moves over to the company’s techical or production support team.  The template I am unveiling here is a formal document to record that transition process, allowing the project delivery team to identify specific things about the project that the production support team will need to know.  While reviewing this document, keep in mind that there are really three very key pieces of information in here that the support team will need to know the most about:

• Schedule
• Communication
• Change Control Process

PROJECT TRANSITION TO PRODUCTION SUPPORT

[Save file name as: client name PRODUCTION SUPPORT yyyymmdd]

PROJECT DESCRIPTION

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

SCOPE

Describe the deliverables/actions to be supported. Provide additional documentation as appropriate.

SCHEDULE

Describe the timing for support activities to be performed. Provide additional documentation as appropriate.

COMMUNICATION

Describe all required communication needs for support – What to communicate, to whom, in what format, and when. Provide additional documentation as appropriate.

QUALITY ASSURANCE

Describe the Q/A processes to be performed. Provide additional documentation as appropriate.

COST

Describe the support costs estimated by the project. Provide additional documentation as appropriate.

CHANGE CONTROL PROCESS

Describe how changes to the Production Support process will be addressed. Provide additional documentation as appropriate.

Detailing the Project Management Audit Process

Diving a little deeper PM audit process as described in the book “Information Technology Control and Audit”, we will look at the audit planning, the actual PM process review, the act of working with the PM and team to identify risk, and the communications necessary to ensure that the audit process is as successful as possible.

Audit Plan

The audit plan will detail the objectives and the steps to fulfill the audit objectives. As in any audit, a project management audit will begin with a preliminary analysis of the control environment by reviewing existing standards and procedures. During the audit, these standards and procedures should be assessed for completeness and operational efficiency. The preliminary survey should identify the organization’s strategy and the responsibilities for managing and controlling development.

Project Management Process Review

A project management process review would assess the adequacy of the control environment for managing projects. The review points listed represent checkpoints in the project management process. Auditors can use these checkpoints to determine both the status of the project’s internal control system and the status of the development project itself. These reviews eliminate the necessity of devoting large amounts of audit resources to the development effort. As long as the development process is well controlled, the need for audit involvement is minimized.

Project Management

Auditors may assist the project manager in identifying project risks and evaluating plans to mitigate and manage risks (e.g., training, devoted resources, management support, and end-user commitment). Auditing can provide management with an independent review of project deliverables (e.g., project charter, task list, schedule, budget). Auditing may also review the project task list and budget to verify that all project tasks are defined and all milestones have a deliverable.

During the planning phase the auditor can facilitate communication between functions and raise issues that may impact the quality or timeliness of the project. In a development project, resources from various departments need to come together to implement an automated process that may affect multiple user functions. Because of various audit projects, auditors develop an overall knowledge of the organization and establish relationships in multiple departments. These relationships are helpful in a development project for making sure information is flowing between the development team and other functionaries. Consider the following groups:

• Primary users
• Secondary users
• Vendors and consultants
• Programmers and analysts
• Database administrators
• Testing teams
• Computer operations
• Interfacing systems
• Implementation team
• Production support (i.e., maintenance programmers)

Verify that adequate resources are assigned responsibility for tasks and have the time to complete assignments. This includes development, computer operations, user, and support functions (e.g., help desk).

Communication

The first area to communicate is the auditor’s role in the systems development project. It is very important to make sure that the management and development teams’ expectations of the auditor’s role are understood and communicated to all participants. In order to influence the systems development effort, the auditor must develop an open line of communication with both management and users. If a good relationship between these groups does not exist, information might be withheld from the auditor. This type of situation could prevent the auditor from doing the best job possible. In addition, the auditor must develop a good working relationship with the manager, the analysts, and the programmers. Although the auditor should cultivate good working relationships with all groups that have design responsibilities, he or she must remain independent.

Recommendations

Throughout the development project, the auditor will be making control recommendations. Depending on the organization’s culture, these recommendations may need to be handled informally by reviewing designs with the project team or formally by presenting recommendations to the steering committee. In either case, the auditor must always consider the value of the control recommendation versus the cost of implementing the control. Also, recommendations should be speci?c, identifying the problem and not the symptom. This allows the proper controls to be implemented and tested.

Recommendations are often rejected because of a time and cost factor. Managers may sometimes feel that implementing an auditor’s recommendations will put them behind schedule. The auditor must convince management that if the recommendations are not implemented, more time and money will be spent in the long run. Informing management of the cost of implementing a control now rather than shutting down the system later to repair it or leaving possible exposures open will help convince management of the need to spend time and money now.

Skills of a Successful Project Manager

In his book, “The Little Black Book of Project Management,” Michael Thomsett identifies his version of the skillset of a successful project manager. I’m providing it here to give you yet another take on some of the key characteristics and capabilities that go into being able to effectively manage an engagement and a team of highly skilled resources.

Mr. Thomsett’s version comes mainly from the viewpoint of a department manager being thrown into the project management role, so understand that this is assuming an experienced manager is handling the engagement, but not one well-versed in project management.

The Successful Project Manager

A successful project manager knows how to bring together the definition and control elements and operate them efficiently. That means you will need to apply the leadership skills you already apply in running a department and practice the organizational abilities you need to constantly look to the future.

In other words, if you’re a qualified department manager, you already possess the skills and attributes for succeeding as a project manager. The criteria by which you will be selected will be similar.

Chances are, the project you’re assigned will have a direct relationship to the skills you need just to do your job. For example:

• Organizational and leadership experience. An executive seeking a qualified project manager usually seeks someone who has already demonstrated the ability to organize work and to lead others. He or she assumes that you will succeed in a complicated long-term project primarily because you have already demonstrated the required skills and experience.
• Contact with needed resources. For projects that involve a lot of coordination between departments, divisions, or subsidiaries, top management will look for a project manager who already communicates outside of a single department. If you have the contacts required for a project, it will naturally be assumed that you are suited to run a project across departmental lines.
• Ability to coordinate a diverse resource pool. By itself, contact outside of your department may not be enough. You must also be able to work with a variety of people and departments, even when their backgrounds and disciplines are dissimilar. For example, as a capable project manager, you must be able to delegate and monitor work not only in areas familiar to your own department but in areas that are alien to your background.
• Communication and procedural skills. An effective project manager will be able to convey and receive information to and from a number of team members, even when particular points of view are different from his own. For example, a strictly administrative manager should understand the priorities of a sales department, or a customer service manager may need to understand what motivates a production crew.
• Ability to delegate and monitor work. Project managers need to delegate the work that will be performed by each team member, and to monitor that work to stay on schedule and within budget. A contractor who builds a house has to understand the processes involved for work done by each subcontractor, even if the work is highly specialized. The same is true for every project manager. It’s not enough merely to assign someone else a task, complete with a schedule and a budget. Delegation and monitoring are effective only if you’re also able to supervise and assess progress.
• Dependability. Your dependability can be tested only in one way: by being given responsibility and the chance to come through. Once you gain the reputation as a manager who can and does respond as expected, you’re ready to take on a project.

These project management qualifications read like a list of evaluation points for every department manager. If you think of the process of running your department as a project of its own, then you already understand what it’s like to organize a project—the difference, of course, being that the project takes place in a finite time period, whereas your departmental tasks are ongoing. Thus, every successful manager should be ready to tackle a project, provided it is related to his or her skills, resources, and experience.

The Most Serious Data Threat May be Sitting Next to You

An article that appeared recently in InformationWeek magazine examines what is sometimes the most serious threat an organization faces in terms of their own data security – the internal authorized user base. The following article from Ericka Chickowski explains that hackers may covet your data, but insiders are the most common source of database leaks.

How IT pros who manage database security rank database threats:

• An insider attach by someone with root access to the database or database server
• A logical attack on a Web-facing app connected to a database
• Database containing confidential data that IT is unaware of
• A misconfigured database
• A vulnerable database that hasn’t been patched

(Data: Enterprise Strategy Group survey of 179 IT pros)

In their quest to protect sensitive information from outside attackers, many organizations overlook the most imminent threat to their databases: authorized users.

“It sometimes amazes me how little concern companies have for their production data,” says James Koopmann, owner of database consulting firm Pine Horse. “They allow nearly anyone to plug in shareware, freeware, and demo tools to access sensitive production data without any concern for how it might be retrieving, caching, or altering data.”

As discussed in the latest Dark Reading Database Security Tech Center Report, five common factors are most likely to lead to the compromise of databases: ignorance, poor password management, rampant account sharing, unfettered access to data, and excessive portability of data.

Take the lack of security education. In our InformationWeek Analytics 2009 Strategic Security Survey, we asked respondents to rate the time spent on various security efforts. User training came in ninth out of 10 choices, a few points behind log file analysis. Yet in another study, CompTIA’s seventh annual Trends in Information Security report, published earlier this year, 85% of those organizations surveyed that do offer security training to non-IT staff saw a reduction in major breaches.

The goal of training must be to ensure that users who work with databases understand the sensitivity and/or financial value of the data they work with, and therefore are less apt to become casual in their security practices.

Poor password management is another common problem. Either IT departments allow database users to set easy-to-guess passwords, or they make passwords so complicated that workers end up writing them down and sticking them to the computer screen.

“We have to strike a balance between ease of remembering for database users versus how complicated we make the passwords to protect against outsiders,” says George Jucan, CEO of Open Data Systems, a database consulting firm.

Account sharing also creates security issues. While some users take advantage of their co-workers’ credentials, others gain access to data via highly privileged application server credentials. In either case, data compromises can occur without leaving a clear trail to the perpetrator. All that log file analysis won’t help you now.

Unfettered access to data is another common problem. In many cases, employees are given access to more information than they need to do their jobs.

“Most of the databases today provide role-based access control to databases, and few companies actually take advantage,” Jucan says. “If somebody doesn’t even see that certain data exists in the database, they will not be tempted to print it and leave it on the printer.”

Enterprises should also look into data-masking technology to limit the user’s exposure to highly sensitive and highly regulated data sets, such as Social Security numbers, without limiting the user’s ability to do his work.

Finally, take a closer look at technologies and practices for protecting data as it becomes increasingly portable. One of the biggest dangers companies face today is the ability of authorized users to simply download large chunks of information from the database onto spreadsheets, laptops, or portable storage devices. Experts say that tools such as database activity monitoring, data loss prevention, and encryption all can help protect portable data.

Project Go – No-Go Decisions – Part 3

Part 3 of this segment comes primarily from Gary Heerkens’ book entitled “Project Management.” Here we are examining the use of financial criteria in determining the best project solution.

Using Financial Criteria for Project Selection

Companies that use project selection and justification methods often rely on financial calculations as a comparative tool and as a basic hurdle for management approval. Basic financial evaluation models—variously known as financial analysis, business case, project financials, or cost/benefit analysis—often include some combination of these four basic metrics: net present value, internal rate of return, payback period, and cash hole. Let’s take a look at each of these metrics in more detail.

• Net present value (NPV). Calculating a project’s NPV answers the question: How much money will this project make (or save)? It’s a calculation in dollars of the present value of all future cash flows expected from a project. It’s roughly analogous to the concept of profit.
• Internal rate of return (IRR). Calculating the IRR answers the question: How rapidly will the money be returned? It’s a calculation of the percentage rate at which the project will return wealth. It’s roughly analogous to the effective yield of a savings account.
• Payback period. Calculating this metric (also known as time to money or breakeven point) answers the question: When will the original investment (the amount spent on the project) be recovered through benefits? It’s typically expressed in months or years.
• Cash hole. Calculating the cash hole (also known as the maximum exposure) answers the question: What’s the most we’ll have invested at any given point in time? It’s expressed in terms of dollars.

Performing a Financial Analysis (or Cost vs. Benefit Analysis)

Each of the four financial metrics identified previously can be determined by performing a financial analysis. Although you may not be intimately involved in performing a complete financial analysis, as a savvy project manager you should understand how it’s done and the terminology involved. The basic financial analysis process is not as difficult as many think. It consists of four basic steps.

Step 1: Identify the Sources of Cash Flows (Inflows and Outflows)

Executing a project causes money to flow out and in. Cash inflows are any financial benefits that can be claimed as a result of executing your project: e.g., an increase in revenue from sales, a reduction in production or operating costs, material savings, and waste reduction. Cash outflows are any expenditures or losses due to the project or its downstream effects. The most obvious cash outflow is the cost of the project itself. However, an increase in operating costs due to the project would also be a cash outflow.

Step 2: Estimate the Magnitude of Specific Cash Flows

In some cases, it will be fairly straightforward to estimate cash flows. In other cases, it may be very difficult. For example, consider how confident you would feel in placing a specific dollar value on these benefits:

• Increased output due to enhanced employee satisfaction
• Improvement in vendor delivery reliability
• Improvement in workforce safety
• Increase in user comfort or convenience
• Reduction in potential legal action against your organization

In estimating some of these types of cash flows, it can be very useful to rely on historical data or benchmark data.

Step 3: Chart the Cash Flows

After you’ve estimated the magnitude of all cash flows, you can chart all cash outflows and inflows year by year throughout the useful life of the project.

Step 4: Calculate the Net Cash Flow Using an Agreed-upon Discount Rate

Because the value of a dollar in the future is less than the value of a dollar today, the value of future cash flows must discounted. In simple terms, it is what the investor (your company) could expect to receive from any other investment that is consistent with its risk tolerance. An NPV greater than zero indicates that your project is expected to provide a financial return that exceeds the organization’s investment expectations, so your project is likely to be approved (if there’s enough cash to fund it).

In Part 4, we’ll further discuss the project decision process by examining the non-financial criteria for project selection.