Project Confusion in Transition Management

A project manager confided she was distressed by complaints from her project teammates and customers; and being bogged down with increasing workloads. Her peers complained about how people on the project relate to one another, and customers throwing tantrums at her and the team without regards for courtesy. Because she engages people on their gripes, she has realized that she dealt with people issues more than in clearing her own work. How should she recover and move forward?

TBH, I tend to think there isn’t a generic answer. I’d say she should have Started off on the right foot at the start of the project. That's harsh :-P .. There should be experience from running projects and lessons learned from past projects – if not by herself, from others on and outside her project team. (In this KA, in assessing stakeholders at the start of a project). Regardless, she is already in the situation. A way forward could be to Ease off from the noise. Gradually change her approach or style in managing her project.

There are many resources and professional help, out there to maybe resolve or deal with the specifics of her predicaments; I’d suggest to –

1. Set expectations on how you'd do your work, e.g. what working framework, ITTO approach, etc. you may lead the project team to adopt and adapt. This includes how you’d manage people – such as do you set goals together with the team and let them do their work. Or do you mostly set goals autocratically and micromanage. Most importantly, do you communicate with clarity and manage expectations consistently.
2. Set guiding principles for success that will help the team in making decisions collectively, e.g. letting subject matter experts do the talking instead of channelling communications through the project manager or office. This is particularly important for your role – do you work on removing impediments and help the team pave ways forward, or do you mostly spend time as a postmaster and fact finding what went wrong. 

It is a commendable principle and practice, by and large, to be attentive, to listen more and acknowledge what was said. In the context of work and that of a project, perhaps conversations ought to weigh in more on what the time is meant for → work lah. While it is virtuous to be human, it can be said there is a right time for the right conversation. Be firm, suggest a time and place for casual chats (if you can, make the time). 

I find it helpful, to steer clear from –

• Characters and emotions.
• Talking about personal desires and affairs while at work.
• Unacceptable actions e.g. hiding information because of mistakes, past decisions, bad feedback, etc.

The contract may require the project team to deliver the following, which could be the final documents or mere guidelines for the taking-over team to expand or improve upon. These are typical:

1. Security Management Plan (SMP) – presents all aspects of security i.e. cyber and physical, which may include matters on health and safety; the latter can be a separate document.
2. Maintenance Plan (MP) – include Analysis of Performance templates.
3. Troubleshooting Guide and-or Recovery Plan – note that knowing the problem doesn't mean being able to recover fully to normalcy.
4. Disaster Recovery Plan (DRP)
5. Training & Exercise Plan
6. Certificates & Certifications – more like a plan to track and update on claims/long term tasks.

When human resources are involved upon handling over a project to business operations, it would be prudent for the project team to consider and present on matters such as on training and certifications. Some pointers on the emphasis, include:

Trainings & Exercises

• Train new personnel, or train for succession particularly when experts are few and they perform mostly on tacit knowledge.
• Update on lessons learned. Organizational support for this process is crucial for lessons to be recorded honestly and factually.
• Improve on maintenance operations. How effective is this process (if it exist) without lessons learned? And sufficient data.
• Practice troubleshooting and recovery of operations including recovery from disaster. Do they?
• Practice handling extraordinary incidents such as emergency evacuation, lockdown, and attack in-situ. It is a question of when it will happen, not if. Don't sweep this topic under the carpet!

Certificates & Certifications

• Competencies of personnel – e.g. may require biennial renewals. This may include certification on health for certain job roles, as well as background checks (could be periodic) for some industries.
• Fit for use e.g. that appliances are calibrated – may require recalibration after certain duration or frequency of usage.
• Licenses e.g. on use of software, from authorities to operate, etc. You wouldn't want a software lockout disaster, because nobody knows there's that license and the software vendor was unable to remind/reach anyone to collect subscription, to renew the license.
• Permits e.g. for personnel to access restricted areas, draw power from certain supply sources within a campus, etc
• Lifespan of e.g. appliances, infrastructure elements, etc. Similar to licenses, you wouldn't want a hardware crash to discover there is no more support or worse- no replacement for the product range.

 See my notes for training on –

• Notes on Handling Over & Taking Over
• Typical project documents for submission (on LinkedIn)

This blog extends my previous notes on what may constitute a document for acceptance tests. The points are brief, and may not reflect what is practiced in your region or project.

Typical information required:

1. Indicate the rational for each test case or that for the test suite - specifically to ascertain compliance to specified or contracted requirements.
2. State how to perform the test for each test case
3. Present the expected outcome from the test case
4. Capture the actual result of each test case
5. Record observations and comment -on deviations from expected outcomes.
6. Attest the test results.

The acceptance test document may include appendices to conclude the test: 

• Evidence of completion of prerequisite tests 
• Evidence of readiness for testing e.g. prerequisite tests were conducted satisfactorily.
• Evidence of calibration e.g. the appliance and-or test tools were recently calibrated and readied for testing.
• Evidence of license - if any is required from the authorities or license owners.
• Statement from the customer - is prepared and ready to accept the deliverables (e.g. on completion of testing with positive results).

There was an incident where the external auditor of the customer, questioned the unfilled frames and scribbles outside of fill-in frames on hardcopy test forms. This occurred despite the testers having been briefed on protocols. The problem here is that incomplete filling and off-witted remarks on a formal test document can cast doubt or uncertainty on the test outcome. 

As such I would emphasize the inclusion of a chapter or section on procedures for completing test cases, i.e. specifically on executing specified tests and filling-up test case forms. Regardless of whether the forms are hardcopies or digital (such as using a purpose driven app on a tablet). I would place this as the first section of the test procedures. It should define information e.g. as follows –

• Capture pertinent details of personnel involved in the tests.
• Provide guidelines on acceptance testing policies, and procedures in completing test cases (note specified test cases are defined in a separate section). This section may include an overview of processes leading towards ratifying the test results (the reason being that each test set or group may have different requirements).
• Sign-off that the chapter has been read and understood before proceeding with the tests.
• Other information may include processes for negative test results (given that time is the essence for work at this stage).
• Additional information could be to indemnify the parties involved in the tests (note that some tests may be conducted live e.g. running hot, a module from DevOps).

See also my notes for training on –

• User acceptance testing
• User acceptance testing - documentation issues
• User acceptance testing - documentation 

The Handover and Takeover process (HOTO as is known affectionately in my circles) i.e. handling-over and taking-over of works affects all of us. These are notes on HOTO for my team newbies :-P

HOTO happens when:

• Someone substitutes a team member. This include when a project manager takes over a project that is already running, or steps in to run a recently secured project.
• A project deliverable is ready for delivery.
• The project ends and transitions to another state.

IMO the most problematic aspect of HOTO is taking over a project; for that matter even taking over an ongoing project activity. The reason being the outgoing incumbent is in the know, whereas the incoming manager is in the unknown. And is unlikely that everything will be made known. The brief below, focuses on the taking over process.

The following steps generalize what should occur when taking over a project, particularly:

1. Size-up the project that you will be taking over – work with the sponsor and project team. Identify outstanding work and qualify whatever may be unknown.  Knowing what is unknown is crucial, especially when you are taking over a troublesome project. Even if it seems to be business as usual, there will be matters that are not documented and may even be hidden. This is where risk and quality assessments will come in handy.
2. Determine the status of the project – the ① present status and ② upon taking over. This will be your assessment of the project status e.g. progress, performance, rates, etc. moving forward - and not that as was assessed in the past.
3. Demarcate responsibilities and accountabilities prior-to handling over and after taking over e.g. who and how would unknowns be handled. Clarify uncertainties. Note that fact finding (from seizing-up the project) is iterative and takes time.
4. Set expectations with all stakeholders, particularly those who may be most affected by the change. This will require time and effort to get to know the stakeholders, and to work with them on what to expect from henceforth. 
5. Inform stakeholders of your expectations.

Similarly, when handling over a project, work with whoever is coming onboard to agree on the status of project, complete all outstanding tasks, and update all project documents. That way you’ll mitigate whatever work you have done in the past from coming back to haunt you.

As with all guidelines, you will have to adapt recommendations of best practices, past experiences, and lessons learned to craft your own processes and procedures. The table below exemplifies common tasks which should be completed throughout the HOTO period:

Exemplify typical tasks before, during, after HOTO

When a project transitions to operations, the project team may have to supply operations or supporting documents (click here) to facilitate smooth operations.

No matter how we hard we try to keep information short and simple, there is still the minimal bits of information we should capture for keepsake. Here are some brief notes on reporting on progress - your approach likely, will be different.

The progress report would comprise minimally, the following elements:

1. Completed tasks – Report on tasks completed within the reporting period. This include unscheduled tasks completed in a time space that may have opened-up during the reporting period. Unscheduled tasks are tasks that were planned e.g. already defined in a WBS, but not yet scheduled nor highlighted for close monitoring.
2. In-progress – Report on tasks that are still in-progress as at the date of reporting, tasks delayed for whatever the reasons may be i.e. these have started, still in-progress but are now behind; and unscheduled tasks if any that were started because of opportunities that arise to launch these tasks.
3. Scheduled tasks – These are planned activities for the forthcoming reporting period.

Use a table for each of the above. Information which normally accompany the above, briefly:

1. Define the task or activity. The activity could be a work breakdown package i.e. an element of a WBS, or a sub-element, or an independent task that just has to be done. Whether work is mutually exclusive for each activity is entirely up to you.
2. Identify the actor responsible for the task – company, role or even a nickname depending on practice.
3. Estimate the start and completion dates. Without which we can't measure performance.
4. Gauge the checkpoint dates to manage work estimates and progress. How checkpoint dates are used (if used) depends on a team’s need and approach to manage resources.
5. Include any other pertinent information that may be useful for, or required by – stakeholders and reporting purposes. Examples may be a task that is delayed, subsequently suspended, and removed from a reporting period. Or whatever which may be of concern for a task or to the project at that point of reporting. 

Additional information for presentation in the report or for the progress meeting, may include:

• Use a full-month calendar for visual clarity.
• Use a burndown chart, for work that were defined for the reporting period.
• List of impediments with reference to the risk register and-or issues log. Resolutions to recent-issues encountered and-or options to impediments may be included here.

Leaving it to you for the format of the report.  Click here for an example of a project progress report.