It is my view that project managers should not test the web projects that they manage.
Assess them yes, test them no.
What I mean by that is that project managers should be able to make an assessment of the condition of the web project by receiving relevant information from QA (quality and test coverage) and developers (progress on outstanding tasks) and having a look over the completed work themselves for their peace of mind.
In some establishments it is accepted that project managers also test their web projects. If project managers are in this position where they have to actually test the web project in detail then problems can occur and that is what this blog post focuses on.
First of all, if you are a project manager then I'm not having a dig at you.
I'm actually trying to showcase why PMs shouldn't test web projects in order for them to achieve more plus enjoy it without the burden of testing (whoever heard of a project manager that enjoyed testing - apart from me, in my previous life as a project manager).
Project managers have a difficult job already, asking them to test their projects too only makes it harder.
So onto the reasons, here is why project managers shouldn't test web projects.
A project manager should focus on what they do best, which is managing projects. A project manager is organising people, keeping a project on track, reporting to stakeholders on progress and dealing with problems as they threaten to derail their carefully planned project. Additionally, project managers are not just managing 1 project but can be managing a dozen or more (depending on their size and complexity).
Testing is at best a big distraction to a project manager and at worse it can completely get in the way of the PM making important and timely decisions at critical stages of a project. Or, the decisions take priority and the testing doesn't.
By enabling project managers to focus on managing rather than testing the project it means that they are not having to fire fight so much, decisions can be taken more carefully, correct planing can be carried out and the PM is better prepared for unexpected events or derailments in their project.
Effective testing requires focus, as does project management. If a project manager focuses on managing the project then the testing is not thorough and if they focus on testing then the management of the project starts to suffer.
Events often conspire against project managers and nothing conspires against a project manager more than when they have several projects all at critical stages, which all require considerable time and effort on their part. Add some testing on top of an already stretched PM and watch how even the most composed PM unravels in front of you.
A project manager has project plans to finalise, functional specifications to produce, wireframes to prepare, meetings to attend, developers to brief, stakeholders to update, technology to keep on top of and all kinds of things to do. And they often have to do this for multiple projects at the same time. They do not have time to prepare test plans, write test scripts and produce test reports on top of all that plus carry out all the testing, raise issues, retest fixed issues and regression test too.
Quite regularly (at least in my experience), the projects that a PM is managing align so that they all require undivided attention and focus at the same time. When this occurs, the expectation that each project should be thoroughly tested by the PM might be asking a little too much.
As good as project managers are at testing, they are not test analysts or QA specialists. They do not always have the tools at their disposal (or knowledge of what tools are best to use), they don't have a bank of test scripts, they are not testing every day and so don't know where to best focus their time and energy.
Project managers don't have time to learn new testing tools, or how they should approach testing a particular feature or component of a website, or know the best Android devices to test an app to get the best coverage or that a new version of some such browser has just been released, which might affect the list of supported browsers for the project (or the next project).
This is because testing is not their specialist subject.
PMs know about RAG charts and Gantt charts and what is in scope or out of scope. They know about how to manage stakeholders, how to manage developers and creative people, how to deliver a complete project on time and on budget. Project Managers can't know testing in enough detail too.
Because many PMs are adaptable, they might know enough to get by, enough to spend some time testing and say, 'that'll do, it is good enough'. But is it good enough? Will it stand up to scrutiny once launched? Will it achieve the quality statements that are often set out in specifications and proposals?
Everyone has heard the saying, 'can't see the wood for the trees'. Well, a project manager often can't see the glaring bug for the nice CSS3 rounded corners and lovely AJAX widgets, or something along those lines.
When you've spent a lot of time working on a web project, constantly reviewing progress and looking at it through all the stages of the project life cycle, it can be difficult once you reach the main testing phase to pinpoint exactly what is incorrect, or broken, or that certain aspects should be better.
There are times when a project manager is simply too close to the project and when testing it is important to have some distance so that it is possible to see everything, warts and all.
Not only has the project manager seen the project at every stage but they have written the specification, planned some of the features, made decisions about how areas of the site should work, consulted with stakeholders and convinced clients that a feature is worth having or spending more money for.
The project manager has invested a great deal of themselves in the projects they manage. This creates a history certainly but also that they have some baggage concerning the project. When testing the website, a project manager may not be able to report issues that would constitute a criticism of their own work or they may find it very difficult to consciously admit that certain features aren't as good in practice as the idea was at the planning stage.
This baggage can get in the way of the testing and PMs may let issues go that other people, not having gone through the same experiences as the project manager on this project, would have raised.
The project manager may not even be aware that this is happening, certain areas of the site naturally become acceptable to them and they are unable to find faults that other individuals would find.
This one might sound strange at first but I really do believe that a project manager naturally, instinctively or subconsciously does not want to find any (or perhaps many) issues.
The reason for this is that a project managers' main objectives are generally:
There are probably several other objectives but those are generally the top 3 for most projects.
Now, consider the testing aspect. A test analyst probably has the following top 3 objectives when testing a web project:
A test analyst usually works within timescales, to an agreed budget and covering an agreed scope but should not have to care about the overall project budget or timescales because that is the job of the project manager.
But when the project manager and the test analyst are the same person then a conflict emerges. How can the project manager raise a large number issues knowing that he or she has to launch the site next week? By doing so they are making their own life more difficult.
A project manager often tests with one hand over their eyes, because if they find a lot of issues then it potentially puts themselves in a difficult position. You could argue that if the project manager doesn't raise the issues then the problems will come to light anyway, just at a later time. However, a person does not normally want to consciously make their situation more difficult by finding lots of issues that could then put the project in jeopardy.
A QA specialist does not really have to think about the implications of finding too many problems. Their main focus is to find anything that could be detrimental to the quality of the project or is not part of the specification.
My main point is that project managers can subconsciously skim over areas or not test as thoroughly as they should because deep down, they know if they find too many bugs then either the project launches on time at a lower quality level or that the project has to be delayed in order to fix the bugs.
And that is a decision that the project manager might not want to be confronted with.
A project manager should glide above a project in order to oversee the full terrain from on high like a hawk, only swooping down into the detail when strictly necessary and then catching a warm breeze to climb back up to their vantage point.
Enough of the bird analogy? Alright then, thorough testing is getting into the nitty gritty detail of a project, often down to a code and pixels level, with web standards and browser compatibility and millions of different versions of Android, making sure forms validate correctly and custom 404 pages are in place or the rounded corners display correctly in IE8.
That is not the territory that a project manager should find themselves, that level of detail related to the testing and any issues found can cause a PM to get bogged down. Certain project decisions then become harder to make because the PM is weighed down by the findings from the testing and it becomes harder for them to see their way clear to a successful outcome.
I believe that it is better that a project manager remains outside of the testing detail and instead is able to focus on the project itself.
We all know that project managers are good at spinning plates but for companies or agencies that expect their PMs to also test as well as manage, there are too many compromises being made and the projects will suffer as a result. If you are one of those companies or agencies, take a look at your project managers, did they have as many grey hairs when they started?
What do you think of the reasons put forward in this post? Do you agree or disagree? Please let me know in the comments.
Photo credit to danepstein
