U is For User
Several years ago, I joined the Project Management Office of a firm that was assembling a team to guide an enterprise wide General Ledger implementation. Previous implementation experience led me to appreciate the importance of end user participation throughout the system development lifecycle, but this project was going to be especially instructive when it came time for User Acceptance Testing.
The end users for the first major rollout were financial accountants. Their monthly consolidation process was archaic, resulting in long, tedious work days and difficulty in scheduling vacation. As a result, volunteers for project related responsibilities were scarce.
Most of the requirements gathering, coding, unit testing and data scrubbing were performed by the Project Team. The User Acceptance Testing plan was prepared several months before UAT was scheduled, allowing time for test script development. Scripting and most testing were assigned to the financial accountants. Their knowledge would be key to determining the complex transactions needed to ensure the system met requirements. Several meetings were held with the Controller, detailing the extent of his financial accounting team’s commitment. He signed off on the UAT plan, assigning leadership to his trusted VP, and assuring his team was on board. UAT Advisor status was assigned to one PMO member: me.
Producing test scripts proved daunting. Disagreements surfaced regarding responsibility for documentation and test execution. The users resisted the increase in workload associated with the project, and attempted to sidestep responsibility for the test script. Closed door sessions with the Controller were called to inform him that UAT might be late due to test script delays. He saw this as no big problem, as the PMO had ultimate project responsibility. I reminded him that his team had responsibility for scripting, but was waved off.
The week before UAT, minutes before a scheduled UAT status meeting, a colleague gave me a “head’s up” that the Controller was panicked that scripts were unfinished, and planned to pin that failure on the PMO – namely me! I quickly made copies of the signed UAT Plan, highlighting the responsibilities of the Controller’s team and my advisory role. I walked into the meeting, saw the Controller, his VP, and 10 other stakeholders, and handed out the copies. Stepping to the whiteboard, I wrote three letters in a vertical stack:
U
A
T
“U is for User”, I started, writing USER in huge letters, then described why experienced end users are required for the UAT tasks in question. The meeting was contentious, with the Controller acting surprised that he had assumed ownership of such key tasks. The VP, complained that her other responsibilities made it difficult to lead testing, and was advised to prioritize more effectively. After the meeting, it was clear to all in attendance why UAT would be delayed.
It took two more months of hard work, grumbling, and additional resources to complete testing. Afterwards, the PMO head summoned me to his office to acknowledge a job well done, and to reassign me to a new project role putting some distance between me and that particular user group. I accepted, gladly.
The end users for the first major rollout were financial accountants. Their monthly consolidation process was archaic, resulting in long, tedious work days and difficulty in scheduling vacation. As a result, volunteers for project related responsibilities were scarce.
Most of the requirements gathering, coding, unit testing and data scrubbing were performed by the Project Team. The User Acceptance Testing plan was prepared several months before UAT was scheduled, allowing time for test script development. Scripting and most testing were assigned to the financial accountants. Their knowledge would be key to determining the complex transactions needed to ensure the system met requirements. Several meetings were held with the Controller, detailing the extent of his financial accounting team’s commitment. He signed off on the UAT plan, assigning leadership to his trusted VP, and assuring his team was on board. UAT Advisor status was assigned to one PMO member: me.
Producing test scripts proved daunting. Disagreements surfaced regarding responsibility for documentation and test execution. The users resisted the increase in workload associated with the project, and attempted to sidestep responsibility for the test script. Closed door sessions with the Controller were called to inform him that UAT might be late due to test script delays. He saw this as no big problem, as the PMO had ultimate project responsibility. I reminded him that his team had responsibility for scripting, but was waved off.
The week before UAT, minutes before a scheduled UAT status meeting, a colleague gave me a “head’s up” that the Controller was panicked that scripts were unfinished, and planned to pin that failure on the PMO – namely me! I quickly made copies of the signed UAT Plan, highlighting the responsibilities of the Controller’s team and my advisory role. I walked into the meeting, saw the Controller, his VP, and 10 other stakeholders, and handed out the copies. Stepping to the whiteboard, I wrote three letters in a vertical stack:
U
A
T
“U is for User”, I started, writing USER in huge letters, then described why experienced end users are required for the UAT tasks in question. The meeting was contentious, with the Controller acting surprised that he had assumed ownership of such key tasks. The VP, complained that her other responsibilities made it difficult to lead testing, and was advised to prioritize more effectively. After the meeting, it was clear to all in attendance why UAT would be delayed.
It took two more months of hard work, grumbling, and additional resources to complete testing. Afterwards, the PMO head summoned me to his office to acknowledge a job well done, and to reassign me to a new project role putting some distance between me and that particular user group. I accepted, gladly.
posted by Steve at 10/11/2006 10:40:00 PM
0 Comments:
Post a Comment
<< Home