Over the course of my career, I have witnessed Project Managers using activity sequencing creatively to “prove” the project could be completed within the specified timeframes and budget.
However, this was a first for me: end-users on a project attempting to use activity sequencing to shortcut their project responsibilities. Or so they thought. I’ll admit, it was creative, but oh so very wrong.
Our project had completed the requirements definition phase. The IT Team began the detailed system design specifications activities. As project advisor to the team of approximately 25 end-user staff, I began to prepare them for their responsibilities in User Acceptance Testing (UAT).
The team members were the best of the best from the end-user community. They came from their day jobs to this long-term project assignment to perform tasks of which they were totally unfamiliar. Over the next several weeks, I instructed them on UAT concepts, introduced them to several testing approaches to help ensure full coverage of the system functionality, and helped them build UAT tracking processes.
Then came the challenge: developing an estimated 8,000 – 10,000 UAT test case scenarios to be ready in time for the delivery of the software for UAT. I extracted several functional areas from the requirements documentation and worked with the team to write UAT test scripts for each variation of end-user testing.
I had met my challenge. Something that comes naturally to IT practitioners – the conceptual extrapolation of requirements to test cases – was lost on these very bright, very capable end-users. They would pull screen prototypes from the requirements documentation and insist that they could not write UAT test cases until they had physically working screens to reference.
Naturally, the process of activity sequencing puts UAT test case creation as successor activities to requirements definition. My end-user team insisted that UAT test case creation activities needed to be successor to system development / system test in order for them to write the test scripts. No matter what I said to show they could write test scripts from the requirements documentation, they could not conceptualize the process without practicing on tangible screens.
I soon understood why they were feeling so lost in this abstract process. Many on the team had been involved in functional testing in the past. They would be pulled into central office from the field for a week or two to test enhancements or major changes to the legacy system. They would “bang on” screens that were familiar to them from their usage in the field, write up errors as they discovered them, retest, then go back to their day jobs. There was no rigor or structure to this process; and they would go back to their offices without knowing whether their testing was adequate or thorough.
Based on this understanding, I was able to coach them in how to write real life test case scenarios that would cover the functional requirements. After all, they had helped develop the requirements and approved them to go forward into design and construction. We wrote several scripts together to help them develop testing scenarios in their areas of subject matter expertise.
I showed them that regardless of the final solution, it was the requirements that they would be testing. After all, a different IT provider may have proposed a different solution, but the requirements for their new system did not change. This revelation convinced them that they could develop the test scripts before the system was delivered, not after.
I promised them they would be trained in the new system functionality when it was delivered for UAT. They would then know how to exercise the system as they executed their UAT scripts.
The team wrote several thousand test scripts over the next few months. Once they understood that changing the normal activity sequence was impractical, and they could move forward conceptually, they completed their UAT test script writing thoroughly and timely.
But isn’t this what we as IT professionals should be doing as a matter of course on our projects? Doesn’t it make sense to thoroughly equip the end-users for their project responsibilities rather than leaving them to their own devices?
That is a correct and much needed application of the people aspects of project management.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.