The project’s big picture is often unknown

When acceptance testing is starting, it’s very useful to know what executions are NOT ready. Usually when inquiring on progress the answer is: “Everything is ready, except a few small things.” Most of time it is not known what those small things actually are.

In my experience, 10-20% acceptance testing defects are not defects, but actually unfinished developments. To find these incomplete issues via testing is frustrating and expensive. It is also completely pointless.

Here are some examples:

• Integrations for third party systems. Some part of these is unfinished
• Change requests made during definition. Especially those that are still not in execution.
• Print-outs have not been finalized or some are missing.
• Executions, that are client’s own responsibilities.
• Open issues, that have not yet been decided upon.

Why we can’t see the big picture:

To put it simply: Process from specification to implementation is not done right. → Client is missing real time view for execution progress in its entirety. Project has scattered into several trackings, that vary with accuracy and realtime. And then there are those hundreds of emails that contain decisions and definitions.

This is how we have done tracking progress

ProjectTOP software is developed constantly. We also do development projects for our clients. In these projects we and the client can see what is finished and what is not – in real time. The whole idea for our development process is:

• In the beginning of the development project we divide the execution to activities on a very specific level, and then put these activities in fitting areas of execution.
• Activities have a specified process: Open – Specification – Specification ready – Decision required – Accepted for building – Building – Ready for testing - Defect logged/Tested OK
• Activities are given a schedule and resources. Activity is assigned to a person who needs to work on it next.

→ We can see who is working on the activity and where the activity is in the process - in real time.

This may vary a little depending on the project, but the tracking basically always goes like this. For example, we can first do all the developments and make executable activities based on them.

Change management, defect management and open issues

What the picture above shows might still be manageable, but when developments, change requests, logged questions and discovered defects start to pile up, the whole thing falls apart. The big picture is lost. This is our solution for that:

• Every development and defect is created as an activity for the project.
• Anyone can log questions about the project. Even these open issues are generated as activities for the project.
• Activities have a specified process. For example, a defect can be made into development.
• Activities are given schedule and resources. Activity is assigned to a person, who works on it next.

→ We can see who has the activity and where the activity is in the process - in real time.

Requirements ←→ Benefits

Building a process as described is successful when three requirements are met:

1. Understanding development project process from start to finish.
2. A common software for everyone in the project is needed (That isn’t a bunch of Excel-sheets and Sharepoint-pages).
3. The desire to improve processes. The ability to lead and communicate.

There are a lot of benefits

• Notable savings on expences.
• Real time reporting and view to project as a whole.
• Clear worklists for resources.
• A chance for project manager to manage project.
• Managing supplier costs and execution.
• In acceptance testing, unnecessary defects mentioned above are not present.
• Planning testing is easier.
• Problems can be solved even before they have occurred.
• When there are multiple projects going on at the same time, tasks as a whole are easier to prioritize.

Then why do things fall apart come acceptance testing?

Many times we are asked to join in the project when the testing is just about to begin. Perhaps because we offer testing software that is easily implemented. At this point the game might be lost already, because the project has scattered. On the other hand, many demanding projects have been successfully finished on time and within budget, when the process has been put to use right from the start.