Search This Blog

Saturday, December 13, 2014

ADKAR – Model for Change

Awareness - What Desire - Why Knowledge - When Ability - How Re-enforcement - Practice




Saturday, November 22, 2014

General Understanding of Project Life Cycle / Methodologies to be Practice in Project Management.

Once you are assigned to any project as PM, and given a Charter / PRF (Project Request Form), perform following in sequences.

i) First thing is to prepare Stakeholder register / Organization Chart.
ii) Meeting with Project sponsor to understand expectation out of this project.
iii) Meeting with Customer / biz leads / vendor’s architect and my org. Solution Architects to understand the business requirement and to setup ground rules for the project. Plan for the design phase till solution is prepared and agreed between parties. Setting up weekly checkpoint meeting to monitor the progress. Simultaneously I will prepare Design Phase Plan, MOM, Financial tracking sheet, Quality plan, Risk & Issue Logs, Project status report, Org Chart, Lesson Learnt Document, Creation of Central Repository and uploading of all the project documents. Update in Stakeholders register and RACI Charts.
iv) Once Solution is prepared, I submit it to Customer Design board along with Budget Estimation for proposed solution review.
v) Once Design and budgets are approved, I acquire project team for execution phase. Kick-off meeting would be setup with new and old resources and all the participant will be abreast about the project scope and solution and delivery.
vi) Next meeting is to identify the task (WBS), ownership, duration, and their sequence. Next big thing is to discuss on Risk / assumptions / constraints and update Risk & Issue logs. Once the entire tasks are identified, I prepare Project Plan and send it to all the stakeholders for their consent. And Baseline Scope, Schedule & Financials.
vii) Then I Schedule recurrent weekly Status Meeting with all the stakeholders, and discuss on the Project status, review project Plan, review past weeks tasks and future tasks and Risk & issues.
viii) I also schedule monthly meeting with team’s functional managers / related service tower leads/SDM to update them on the project progress / team performance / Risk & Issue.
ix) Update project reports /plan / financials tracking every week and send it to higher management. Entertain and manage project change request, accordingly updates project baselines.
x) Send task / milestone completion / status mails to stakeholders, receive sign-offs and upload these evidences in the Central repository.
xi) I use EVM to monitor project health for schedule and budget.
xii) Co-ordinate with vendor and financial dept. for any procurement from vendors/ 3rd party and manage their approval and delivery.
xiii) Once project received all the sign off and delivers what was in the scope, I begin with project closure process.
xiv) Confirm that all the tickets / task are completed and closed. Confirm delivery of the product with customer and save this communication. Release all the resources from the project. Close project financials. Prepare Project closure report (update any open item / task with proper reasoning, new owner, and estimated date to finish) & Lesson learned documents and obtain sign off.
xv) Obtain project closure approval / sign offs and close project in Project Management systems / PPM system and close the entire task in Project Plans.

Tuesday, November 11, 2014

What change Management processes we should use to ensure that change is introduced properly?


Change management deals with how changes to the system are managed so they don't degrade system performance and availability.

In effective change management, all changes should be identified and planned for prior to implementation. Back-out procedures should be established in case changes create problems. Then, after changes are applied, they should be thoroughly tested and evaluated.

Step 1: Define change management process and practices
As you would with other systems management disciplines, you must first craft a plan for handling changes. This plan should cover…..
A. Procedures for handling changes—how changes are requested, how they are processed and scheduled for implementation, how they are applied, and what the criteria are for backing out changes that cause problems
B. Roles and responsibilities of the IT support staff—who receives the change request, who tracks all change requests, who schedules change implementations, and what each entity is supposed to do
C. Measurements for change management—what will be tracked to monitor the efficiency of the change management discipline
D. Tools to be used
E. Type of changes to be handled and how to assign priorities—priority assignment methodology and escalation guidelines
F. Back-out procedures—Actions to take if applied changes do not perform as expected or cause problems to other components of the system
Step 2: Receive change requests
Receive all requests for changes, ideally through a single change coordinator. Change requests can be submitted on a change request form that includes the date and time of the request.
Step 3: Plan for implementation of changes
Examine all change requests to determine:
A. Change request prioritization
B. Resource requirements for implementing the change
C. Impact to the system
D. Back-out procedures
E. Schedule of implementation
Step 4: Implement and monitor the changes; back out changes if necessary
At this stage, apply the change and monitor the results. If the desired outcome is not achieved, or if other systems or applications are negatively affected, back out the changes.
Step 5: Evaluate and report on changes implemented
Provide feedback on all changes to the change coordinator, whether they were successful or not. The change coordinator is responsible for examining trends in the application of changes, to see if:
A. Change implementation planning was sufficient.
B. Changes to certain resources are more prone to problems.
When a change has been successfully made, it is crucial that the corresponding system information store be updated to reflect them.
Step 6: Modify change management plan if necessary
You may need to modify the entire change management process to make it more effective. Consider reexamining your change management disciplines if:
A. Changes are not being applied on time.
B. Not enough changes are being processed.
C. Too many changes are being backed out.
D. Changes are affecting the system availability.
E. Not all changes are being covered.

Monday, November 10, 2014

Centralized Vs. Decentralized PMO

PM’s usually work on two modes of models in most of the companies…
  1. Centralized PMO which is accountable for delivery of projects, has HR responsibility for the PMs and owns the process/metrics/tools. In these models PMs are dotted lined into business segments.
  2. Decentralized model which has PMs directly aligned into business segments but have dotted lined responsibility back to the PMO to ensure standards.
I have worked in both models and think there are pros and cons of each. Some benefits of a centralized PMO include:
  1. Ability to build a sense of community because everyone is together
  2. Ease of rolling out standards because there is a direct alignment of standards and the PMs
  3. Ability to rotate resources to different areas in the case of volatile demand across business segments
  4. Consistency of work
Some benefits of a decentralized PMO include:
  1. Closer alignment of PMs to business segments and the ability to become an expert in the business of that segment
  2. PMs can report into segment managers so there is not as much overhead as a PMO
I think there is validity in either model and it really depends on the organizational culture and values. If consistency is a top priority then it makes sense to centralize. If being nimble and operating at a segment level is a priority, then decentralization makes more sense. Having a hybrid model is probably the best scenario – for example having a centralized organization but then keeping the PMs aligned to specific segments and not moving them around too much.



Friday, October 31, 2014

ITIL and PMP Framework Similarities

While ITIL addresses how IT organizations as a whole should operate, PMP addresses how individual projects within the organization should be executed. PMP applies to projects throughout the entire organization not just IT. Both frameworks rely heavily on process and the use of tools to enable consistent execution of processes. The ITIL framework and the project management framework support each other in a way that propels services and operations to a greater level of proficiency. Furthermore, both frameworks address the need to manage quality, risk, and accountability. Most importantly, however, both ITIL and PMP consistently help improve efficiency and usefulness within the organization. ITIL describes the ideal end state that an organization would like to achieve. There are those who believe that if the ITIL framework behaves according to the ideal model, all will go according to plan. Unfortunately, this impractical IT end result is not realistic in the business world - and an organization must implement a framework that allows for individual projects to be completed over months’ time in order to get to the desired end result.

Tuesday, October 14, 2014

Differences between ITIL and PMP

The differences between the ITIL framework and the project management framework are inconsequential when compared to the overall effectiveness of combining the two. Similarities aside, project management is not specific to IT. The PMP framework, focusing on effective execution of projects, can be applied to any area of any organization. Unlike ITIL, the project management framework does not operate on a lifecycle approach, but is organized into nine key knowledge areas: project integration, scope, time, cost, quality, human resources, communications, risk, and procurement management. As previously mentioned, rather than analyzing the breakdown of each project, the ITIL framework examines the whole picture - a key difference. By taking a larger view of services in the organization as a whole via a lifecycle approach, ITIL sets out to examine service strategy, service design, service transition, service operation, and continual service improvement. Take, for example, an organization that is building and deploying an email service - on one level, ITIL will evaluate what is needed; PMP will then take this information and further break it down into easier-to-manage increments.