Project Confusion in Transition Management

These short notes are expanded from the previous blog article.

The project progress report may present concise information such as – 

1. % Completion supplied from a project management tool
2. Accomplishments & Plans moving forward to the next reporting period.
3. Risks & Impediments for notification and guidance of the project management steering committee.

Information may be presented on a presentation deck or a simple single page i.e. pdf. The % completion may be on schedule completion or cost completion, or computed in a method agreeable by all parties. A reliable tool is usually adopted for the purpose.

For impact, include a calendar to highlight visually the workload of the project, e.g.

This article continues from my notes on acceptance testing in my region. The acceptance report or UAT Report as is typically known, is outlined here —

A UAT Report may be progressive such that it presents the summary of acceptance tests that are in progress at any time a report is needed, or a summary of concluded acceptance tests. It records the aggregation and or finality of test results, observations, discrepancies/deviations from the RTM, and resolutions if any that were made during the course of testing. 💯

The report may include out of scope testing such as tests or retests brought forward from a previous UAT regime. Or mention of (significant) outcomes from testing beyond formal test cases.

The final report is usually signed-off by the parties involved. The document may serve as a binding document that the planned tests are conducted, and present plans i.e agreement for completing whatever else that may be outstanding after the tests.

A UAT Report may comprise contents e.g.

A UAT Report in essence-

• Presents a consolidated view of what has transpired. A historical record on the build (where possible); especially when things were made on the fly and lacking as-built documentation.
• Is applicable to everyone- and produced by anyone- with vested interest in the testing or project. Anyone authorized can contribute to the construction of the report. 
• Emphasizes the terms to close a project phase (stage or work component) and move on to the next. The terms may include newly negotiated terms to deal with doubly unknowns uncovered during testing.
• Plan it as the end goal in testing. Exploit it as preparation, but to publicize structures and processes leading to the conclusion of testing. 

How do we create an acceptable UAT Report?

• Gather evidence of work outcomes as project progresses e.g. to ease documentation.
• Build upon a template that everyone is agreeable with. An approach visible to everyone is to evolve the report, editable by authorized users on a shared repository.
• Involve stakeholders that matters in crafting and reviewing the report, both formally and informally. As the saying goes, engage stakeholders early on in testing ('the project'), and bring onboard influencers in completing the testing.

References & past notes on the same topic:

• User Acceptance Tests 
• User Acceptance Tests (documentation issues)
• Notes on Documenting Acceptance Tests
• Doomed from the start: the importance of developing a sound test plan (2001)

.

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