Working as Project Leader using Project Management, Lean Business Analysis and Test Management skills, Aimee Palmer recently delivered a client project where visual task management was adapted to suit the needs of the project team during the project lifecycle. She explains how this benefited the team and the overall project…
As there was very little implemented framework to follow within the organisation, I soon realised that my planned tasks needed to be transparent for my project sponsors, business representatives and other key stakeholders.
During the delivery stage, we adapted the visual approach to help the growing team focus their daily work to the key areas. I used three Visual Management board variations – the first adapted for overall project delivery, the second a further adaption, and a third specifically to manage testing and issues for the duration of system testing. The stand-out benefit was a dramatic reduction in time wasted on repeated communication.
Board 1: Project initiation / design / build – simple
Being new to the client organisation, working on a part-time basis with scant framework around project management and no business analysis framework within the organisation, for transparency I developed a simple board and placed it in the thoroughfare of the main stakeholder team’s office where it generated lots of interest. This board included a short description of what Visual Management is (see A, fig 1).
Every week, I took the business representative through the work in progress (WIP) and expectations for the coming week, using the board as the focal point. Recognising the value, we also started to manage his tasks on the board. Before this, we would often have lengthy conversations about tasks further down the line – so being able to just place an ‘Epic’ task on the board meant it wasn’t forgotten and allowed us to focus on what was needed for that week.
When I was out of the office, the business could also see what was being worked on at any given time. We used markers such as ‘Blocked’, ‘Ready’ and ‘Highest Priority’ (see B, fig 1) to indicate the prioritisation around tasks, moving the project through project initiation to build.
Board 2: Project delivery – quality / organisation change – milestone-specific
As the project moved into delivery and the team grew, we needed to create a project space where the team could focus on testing. The project room seemed a more appropriate location for the board. With more team members involved and tasks shorter than a week, we also introduced a ‘stand-up’ three times a week, time-boxed to 15 minutes.
It then started to become difficult for the team to locate tasks on the board. Stand-ups would run over because the team had to spend time sorting through the backlog so we introduced categories in the form of swim lanes on the board – system testing, user acceptance, training, business process, project management (admin), cutover/communications (see A, fig 2). As milestones were completed, new focus milestones – such as ‘launch’ – were brought onto the board. This made the stand-ups more efficient as priority items could be located and dealt with.
The board quickly became crucial for the team’s work planning and tasks they needed to complete. They took responsibility for work they were assigned to and regularly updated the board either themselves or through me. One team member stated that “It feels pretty good to move something to done”.
With the swim lanes clearly illustrating the key milestones and tasks, we had all the planning we needed. We could plan a few days ahead and mark our backlog with the week day on which we expected to pull the task into WIP.
Board 3: Systems testing / issues management – dual board
As the team moved into testing, I wanted to ensure we had a snapshot of the testing coverage and status of resulting issues. The testers were our end users so it was necessary to fit the testing into their ‘day jobs’. Although some base scripts were provided for each of the process areas, I wanted the team to use their experience to add additional tests as required. For the in-house parts of development, we took an iterative development approach so it was important to track any additional requirements through testing. Although ‘system testing’ was a milestone on the main project board, it was only used to track the major tasks (such as where we had a defect with the external vendor).
The separate elements of this board were as follows:
Testing – ‘To Test’, ‘Testing’ and ‘Complete’ (see A, fig 3)
Base tests were captured in the test management tool – Oracle Application Testing Suite (OATS) – and grouped into sets according to the process they covered. These test sets were then listed on the board and the relevant tester assigned. The team would work through their tests and, if an issue was uncovered, it was loaded in OATS (to capture the steps to recreate the issue and its resolution). A small tab (see C, fig 3) was then added with the issue number to the Post-it to indicate that the set of tests was not completely passed. If it was a blocking issue, the test set Post-it would remain in the testing column.
Issues – ‘Issue’, ‘Under Review’, ‘Ready to Test’ and ‘Completed’ (see B, fig 3)
Each issue/additional reporting requirement was tracked. It was encouraging to see the ERP specialist come in at regular intervals to run his eye down the issues and update us with the status of his issues – and also to see the beaming faces of the testers when they had completed a test or retest and moved a Post-it! At any time, I could very easily gauge how we were going with the testing.
For me as Project Leader, the adaption of visual management for each project stage was very effective in helping manage multiple workstreams/milestones. The flexibility and simplicity of the boards allowed for adaption to the different stages and were used to complement electronic systems and other boards in an overall process. Other benefits to the business included a base framework within which to work, transparent communication, current status reporting and the ability to record important deliverables for later consideration in the project.
This avoided lengthy discussions and provided a visual mechanism for tracking core tasks when needed, as well as the development of a positive team culture – the result of each team member’s work being visible, while giving them the satisfaction of regularly completing tasks.