Project Management

Project Confusion in Transition Management

by
Projects are about transition from one state to a desirably better state. Management is often viewed as a source of confusion. So lets break down the confusion and build up the means for transition to meaningful deliveries.

About this Blog

RSS

Recent Posts

Notes on Reporting Progress (ii)

User Acceptance Tests (documentation)

Start Right

Documents Supplied for Post-HOTO

Notes on Documenting Acceptance Tests

Categories

Agile, Agile Communications, App design, Communications Management, Give-back | Outreach, information communication technology, New Year, PMIef, Project Management, Quality, Risk, Risk Management, System design, Volunteering

Date

Notes on Reporting Progress

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 reportClick here for an example of a project progress report.

 

 

December 2021

 

Sun

Mon

Tue

Wed

Thu

Fri

Sat

 

 

 

1

Complete stress test

2

Rectify stress test results

3

 

4

 

5

 

6

Progress report & Jan. schedule

7

 

8

 

9

 

10

 

11

 

12

 

13

Construct modules for Phase 2

14

 

15

 

16

 

17

 

18

 

19

 

20

 

21

Test modules

22

 

23

Complete module tests

24

Rectify results

Plan for integration 

25

 

26

 

27

 

28

 

Posted on: April 18, 2022 04:46 AM | Permalink | Comments (1)

Agile Unintended

My project involves the deployment of reliant systems for aviation safety. The project was called, tendered, & awarded as waterfall. At the start of the project, there were unprecedented, IMO irrational new requirements with a mandated condition of urgency to complete the project ahead of schedule.

With unanticipated new requirements, there was a sense the project will need a different approach to management if the team were to keep to the proposed timelines. It didn't happen. Because interestingly nobody could agree nor willing to deep dive into project management methods!

So the project continues with negotiated mindless commitment to accommodate to needs, wading through waterfall demands that are difficult to compromise. Our upside of commitment is cohesive customer-vendor collaboration; developed through working in proximity. But it could easily go the other way.

This brief presents the lessons learned in introducing & adapting Agile in a contracted waterfall project. The introduction which was unintendedunplanned for. Where Agile is informally practiced. 

The project eventually settled into a regime that emphasizes meeting deadlines on essential deliverables. And communicating developments particularly issues verbally & in a timely manner. Compromises were made on:

  • Reporting progress through unconventional means ie. through text messaging on a medium that is familiar, effective & comfortable with everyone e.g. sharing pdf files, diagrams, scribbling on images.
  • Resolving problems without meeting formally, keeping everyone informed & updated using the same medium (additionally in our case we quietly ditched the CCB process).
  • Reducing or setting aside for later- formal paperwork. 

Now in its final stages, the project runs & feels like an Agile project. Where communication is key to keeping everyone updated on progress & ready to resolve problems, if any arises. It is informally Agile with prescribed waterfall submissions, minus the embellishments typical of Agile methodologies.

Our Lessons Learned 

Thus far, we applied with intent the following:

  1. Plan just enough. Let the project & plans evolve. Help the project team get comfortable & agree to planning with whatever information is at-hand.
  2. Lead the customer. Take time to demonstrate & tweak processes towards the Agile framework.
  3. Trust the project team wholly. Most importantly trusting the customer to deliver their part.
  4. Apply Agile at the level of comfort for everyone involved. There will be people who are ignorant or resistant to the approach. Work on processes instead of convincing everyone.
  5. Meet waterfall obligations. This sounds counter-intuitive when applying Agile practices; however there are always protocols that must be followed e.g. contracts especially in procurement, warranty claims, billing cycles.

Success factors 

My take on our success, in addition to the above lessons:

  • Customer is aware of Agile - the customer had prior organisational training but not the experience in practicing Agile; and 
  • Customer is 100% willing & committed to attempt a different approach to complete the project.

The project team continues to maintain & prescribe project management functions e.g. QA, risk assessment on work packages. Work now runs on a fast track. Yet without compromising on essential tasks e.g. audits.

Agile Communications 

Stakeholders simplified communicating project performance & progress, both formally & informally primarily to:

  • Report on accomplishments 
  • Inform on immediate scheduled plans & work about-to-start 
  • Highlight & work to resolve problems

 

Tip! - Keep reporting on progress & performance to a minimum but at an acceptable level or standard. Check with the customer regularly for feedback on communications & clarity. 

Posted on: January 07, 2020 10:02 PM | Permalink | Comments (9)
ADVERTISEMENTS

"Not all chemicals are bad. Without chemicals such as hydrogen and oxygen, for example, there would be no way to make water, a vital ingredient in beer."

- Dave Barry

ADVERTISEMENT

Sponsors