Project Confusion in Transition Management

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.

There are two scenarios which can get us caught unawares when a project task or activity is delayed. It is either ① we failed to manage and monitor the activity, or ② there isn’t one or an adequate risk response plan for that activity. Taking over an activity that is delayed is to firefight - the implications are on the project team, the organization.

If we failed to track progress of the activity, then it could be construed as negligence; perhaps due to incompetence or ignorance e.g. that there is no succession planning (known unknown) or no certified professionals doing the job (unknown known). If we don’t have a risk response plan preferably in writing or in our heads or have some clues, then we would have totally failed to implement risk management.

Granted that events can happen unexpectedly – we should nevertheless have been on top of things. To begin with - there should be some form of risk management plan as the project kicks off.

Here’s my summary - when a risk event occurs, broadly:

Here are some principles to follow:

PMBOK® Guide – Sixth Edition (2017)

Past notes

• It Is About People
• Ignore Risk at Your Own Peril
• Risk on the Fly

This article continues from my notes on acceptance testing in my region. A broad view on documenting acceptance tests.

There are different ways to manage documents when testing for compliance to contracted terms (specifically with reference to the RTM). Given that at the end of the project, there could many test documents whether digital files and-or in hardcopies, generated for review, reference and filing.  One common approach is to log everything as a single file, and the other is to use multiple files.

Generally, there are two parts that need validation from stakeholders, particularly the customer – on the test procedures, and thereafter on the results from executing the test procedures. Hence a test document, would comprise minimally the test procedures and the means for recording the results. Taking it further, there may be a section to ratify the test results, and other sections for whatever else that may be included.

Logging everything into a single file may apply for the entire project (complex or otherwise)! Or may apply for a cluster of project components – let’s say. As hardcopies it would produce a single document with a single index that could span across multiple physical folders. And there would be hand writings and signatures on the hardcopies.

Logging multiple files is straightforward, i.e. one test document for each component or part. These may go into a single physical folder or span across multiple physical folders. Or each test in its own folder. The difference here is that information such as on test procedures is generally replicated, and each file will have its own file index.

Logging acceptance tests as digital files is similar as to logging hardcopies. For certain, there are better perks in logging digitally. Details on logging digitally in another blog.

Sounds straightforward ya. But what if for whatever the reasons may be, someone decided that the test procedures and test results should be filed separately. And (worse) there should be a file for each component or part. What could happen?

Here's a list of possible outcomes, from my recent and past experiences:

• Files inadvertently, even expectedly went missing because there were no proper, decisive, and thought-through means to relate, link and index the various test files together.
• Revisions were made to test procedures and related documents for subsequent tests without careful consideration for tests already conducted and filed in the past. Although the test intent may be the same, the approach and document formats are now different.
• The project is specified to conclude as a whole project. Understandably, any negative test result would impact the delivery of the project. By (re)specifying test reporting as multiple submissions (whoever did ..), the supplier/contractor argued successfully, that positive test results should be accepted as-is, and that the faulty component is independent of the rest. The point being the fault lies in a redundant portion of a system. Even though the system test should have resulted in an impact, the case was not – it was accepted that the system can perform and has performed accordingly to specifications; just that a component (or few) was down which can be and was easily ratified.
• Much time is required to search, corroborate, update and validate data or information, when similar purpose records are filed in multiple files. Imagine if the files are held by different individuals and not updated on time to a common repository.
• A deemed-independent test or case file may be closed in itself; but it may have impact on future activities in both technical and non-technical aspects. This can create issues in the long-term, which may surface after the project completes. Keeping pertinent case files alive such as in one collective file (for ease of reference/retrieval etc.), can reduce problems such as (non-apparent) issues being side-lined or neglected as the project march towards completion.

My take on documentation; including test documents —

1. plan your project documentation journey as early as possible in the project;
2. sleep over your document drafts, solicit inputs and revise them for their purpose. Whatever the approach may be, at the end of the day, IMO it will be the terms and how the terms are interpreted, which will dictate what project and acceptance test documents are like.
3. also read this

This article are notes from a short short half-hour exercise in brainstorming.

Problem Statement

Accredited volunteers of a uniformed neighborhood watch scheme are mandated and committed to serve 2 hours monthly, on patrols scheduled weekly. Participation of volunteers have dwindled since it inception to almost zero. A list of possible activities are needed to complement the patrols and excite volunteers on otherwise dull and routine walks around the blocks and parks - hence a brainstorming exercise was called to create the list.     

Prior to brainstorming, contributors were informed of the purpose of the scheme. Additional information include —

Rules of engagement (ROE)

• Observe - to support the community and project a presence of safety. Volunteers observe their surroundings, the environment; comings and goings in the community during their patrol. This applies to - only watch, when the patrol stumbles into incidences such as graffitiing in-progress. If the incident is not life threatening, they should first consider their actions before acting - if at all.
• Record - whatever that may be of interest, take notes written, voice recorded or photographed for documentation, that serves the objective of the scheme. In the example above to record the graffitiing incident.
• Report - whatever incident of concern or as required by the law. In the example above, as the volunteers may be sought as witnesses (provided they consent).
• Personal Safety First and foremost; personal safety is paramount as volunteers are members of the public themselves. Volunteers have attended minimally public safety training and inducted themselves to RHT when an occasion warrants it.

For each patrol session, the following are conducted (by the assigned lead):

From brainstorming, we formulated a list of what the neighborhood watch team could do when on patrol, on different weeks, that may include activities such as "looking out" for:

• abandoned vehicles e.g. bicycles
• blocked walkways, emergency exits and staircases
• conduct patrols on bicycles (conditions apply)
• emergency utilities & appliances such as fire hydrants, AED, emergency lighting - note the location & condition
• first aid practical
• graffiti and signs e.g. indicating presence of untoward activities
• indiscriminate parking
• indiscriminately tied cables/ropes/strings/wires
• littering outside residential blocks
• leaking pipes e.g. water pudding 
• local celebrations & festivities 
• morning breakfast meeting
• note distances - actual or estimated distances
• note unregulated & modified vehicles
• note condition of children's playgrounds incl. the exercise yards
• note where are the public electrical sockets
• note where are the public water taps
• places of interests within and around the estate.
• possible hiding places.
• public education e.g. Internet scam advisory etc.
• public education on emergencies e.g. in the event of a fire
• public education on green environmental e.g. recycle, reduce,  reuse, repurpose
• safety at the car park e.g. oil leaks
• safety of cyclist within and around the estate
• safety when handling pets
• stray animals e.g. health of neighborhood cats
• supermarket trolleys left around the estate
• TOPSIS (security) awareness 
• visit residents in-need or celebrating occasions (where possible)
• walk with pets (conditions apply)
• wildlife e.g. learn about the many species of raptors that fly by the estate from the nearby nature park or from across the border

Without going into the why, what, how-to - broadly each activity may involve, such as to:

1. create list e.g. on what was observed while patrolling the neighborhood
2. compile statistics
3. correlate data/information with that from past events/activities

Now that we have a list, what do we do next?