Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Information Technology
Transition from Project to Production
I have been involved in software implementation project for 3 years, and now we are working to transition from "Project" to "production" environment. There are limited resources ( grand total of 11 analysts/programmers for an extremely complex system), and we have been experiencing high turnover rates. The technical resources are divided into two different areas, half reporting to the IT director, and half reporting to the functional area. In moving to a "production" environment, I am being told that all these resources should report to the IT area. Problem is, that throughout the project life, the IT resources have repeatedly been pulled away from tasks, not sent to training, and missed critical deadlines, while the IT folks on the functional side have put forth extreme effort to keep us on track. Needless to say, there is some animosity between the two groups, and extremely different perceptions of levels of responsibility. The functional sponsors of the project fear that the move to IT, while creating opportunities for the IT folks within the organization, would result in the abandonment of the systems we have worked so hard to put in place. Please note, the IT Director and the Functional Sponsor do not report along the same lines in the organization, and natural differences in what is considered priority at the organizational level occur. Any suggestions on how to address this issue, or experiences others may have would be welcome.
Sort By:
Page: 1 2 next>
Hi Jennifer,

This situation has got to be frustrating for you. Here are some things to consider:

* A basic cause of this problem is the inadequacy of the hybrid organizational structure you are in. Splitting a team between two lines of authority is difficult at best and you gave good examples why.

* In your case, it does not sound like there is accountability for reduced production resulting from removal of resources. You should calculate and communicate the business impact of this reduced production. Link it to profitability, customer service, whatever. Then it will be clear what the financial consequences are prior to the decision being made to pull out resources.

* Make sure you communicate this fact clearly and politely. Often, decision-makers are not clear on the consequences of their actions (Say it isn't so, Joe!) especially when it comes to morale, turnover, and excessive work to "cover" reassigned resources.

* Avoid sounding like you are whining. The decision-makers are not interested in your project problems directly, only the business impact they may be missing.

* To get around problems with differing priorities and confusion over levels of responsibility, replace hierarchy by establishing a project-specific structure (system of controls) for approving, decision-making, and troubleshooting. Develop it by consensus with project/business success as the goal, as opposed to turf or departmental rewards.

* Keep an open mind to the fact that overall corporate success may mean that you have to face reduced staff, albeit temporarily. Be magnanimous as a corporate player and negotiate reduced production expectations for your team during these times.

Good luck!
Hello Jennifer,

I agree with what Joe Wynne suggested and there are business political issues that you would do well to keep clear of.

It will help with the communications aspects if, as part of the transition from project to production, you arrange for Service Level Agreements (SLAs) to be implemented. These SLAs will set out the responsibility of the IT department, as service provider, to the Business, as service recipient and agreed by both parties. The Business will know what benefits the system will deliver (increased revenue, avoided cost and stuff stated in the original business case), the costs to be expected if the service fails as well as an expectation of the day to day running costs.

The SLA should define in clear and unambiguous terms:
„X what is being promoted to production status, when and how,
„X who will support it (for changes, for operations, for hardware problems¡K) and how,
„X what uptime is required,
„X what availability time is required,
„X what response times are required,
„X what transaction volumes are to be supported,
„X the number of users,
„X the number of sites,
„X the hardware specifications to be supported,
„X the network infrastructure to be used,
„X backup and security policies,
„X business continuity and disaster recovery procedures,
and so on.

From this the running cost of the service can be derived (including transaction costs, service costs etc) and the means by which the Business can be compensated if the IT service is not meeting the SLA.

The SLA then acts as a type of contract, or means of measurement, of the IT service provider in delivering the service and this can be reviewed monthly or whenever (weekly if necessary) so that appropriate charges to the Business can be made. If IT must pay compensation for poor service, there is more incentive to resolve the internal problems in order to deliver the required service, especially if the SLA is reported to senior corporate levels. The Business must set up a means of monitoring the contract and escalating any issues with the IT department.

Hope this helps.
Hello Jennifer,

I agree with what Joe Wynne suggested and there are business political issues that you would do well to keep clear of.

It will help with the communications aspects if, as part of the transition from project to production, you arrange for Service Level Agreements (SLAs) to be implemented. These SLAs will set out the responsibility of the IT department, as service provider, to the Business, as service recipient and agreed by both parties. The Business will know what benefits the system will deliver (increased revenue, avoided cost and stuff stated in the original business case), the costs to be expected if the service fails as well as an expectation of the day to day running costs.

The SLA should define in clear and unambiguous terms:
* what is being promoted to production status, when and how,
* who will support it (for changes, for operations, for hardware problems…) and how,
* what uptime is required,
* what availability time is required,
* what response times are required,
* what transaction volumes are to be supported,
* the number of users,
* the number of sites,
* the hardware specifications to be supported,
* the network infrastructure to be used,
* backup and security policies,
* business continuity and disaster recovery procedures,
and so on.

From this the running cost of the service can be derived (including transaction costs, service costs etc) and the means by which the Business can be compensated if the IT service is not meeting the SLA.

The SLA then acts as a type of contract, or means of measurement, of the IT service provider in delivering the service and this can be reviewed monthly or whenever (weekly if necessary) so that appropriate charges to the Business can be made. If IT must pay compensation for poor service, there is more incentive to resolve the internal problems in order to deliver the required service, especially if the SLA is reported to senior corporate levels. The Business must set up a means of monitoring the contract and escalating any issues with the IT department.

Hope this helps.
Where can I find an example of a Moving to Production strategy plan?
I would be interested as well as in a "Moving to Production" strategy plan or document template. Our team supports application development and immediate post-implementation. As we begin the transition to support, I discovered that there have been no agreements to adequately cover delivery to our IT team and their help desk support. I am creating a "Help Desk FAQ" and outlining our contacts, but it seems insufficient.
Suggestion: Instead of a Moving to Production Strategy plan or document, why not include these deliverables as part of your project plan implementation to production milestone and subtasks. Obtain production support members to join the team about 1-2 months prior to implementation (depending of course on the project size and deliverable turn around)... Or better yet have them join at the beginning in the planning phase, so that they can determine for you what they need. They can identify the deliverables they would require from others such as an implementation notification, Valid implementation schedule dates, Support documentation they will need outling things like code being changed (for development departments) etc. these may already be your design documents generated at the beginning and now need to be updated as as built documents. End-user training documents or first points of contact etc. Anything that would be specifically needed for your organization would then be identified for you by the team member accountable. Hope this helps... Oh I also find a common web site (intranet site) useful for the company especially with main contacts ...
I also would be interested in a "Moving to Production" strategy plan or document template, particularly for the communications and (organizational) change management aspects. I'm part of an OCM team that's working on a BI implementation that has multiple implementation/deployment cycles that requires multiple responsibilities for communications and CM-related activities from OCM for the pre-deployment tasks, and how to successfully transition these tasks to production support for the post-deployment groups.
In reviewing this thread, i see several requests, some good content, but no real examples of templates or best practices for transition documents. I'm in the process of updating our document and am curious if anyone has any examples/guidance. I'll post this in the hopes of bumping this into an active thread.

We maintain separate documents that define SLAs and support agreements for our systems. These are updated or created as part of the project scope (though not always, and not always well).

I'm actually trying to come up with a purpose/scope statement for the turnover document itself. I know I want it to include:

- Items that have changed or are impacting to the the system support resources since the last touchpoint in the project (which would have been design or maybe test case review)
- Minor changes to production schedules that wouldn't be included in the document I mention above, such as new or changed batch schedules, one time processes at implementation, etc.
- Implementation risks that would impact support groups (potential help desk call drivers, etc.)
- Links to other support documents, such as business procedures, design documents, project overview, SLA document
- Warranty Support schedule

But I wonder if there are other items that should be addressed that I haven't thought of that would be value adding here.

Thoughts, anyone?
I came across this template created by Princeton University, I hope it helps.

File attached.

Thanks! That doesn't have what I'm looking for, but is a good process template. I am going to put that together too, to go with the template for the turnover documentation. Appreciate the help!
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Karate is a form of martial arts in which people who have had years and years of training can, using only their hands and feet, make some of the worst movies in the history of the world."

- Dave Barry

ADVERTISEMENT

Sponsors