Is stakeholder management important in project delivery? – A Testers Perspective
I have been a tester for nearly 15 years and, during this time, have built up a strong belief that good stakeholder management is key to streamlining project delivery. Here’s why:
Success in IT project delivery is often measured in silo’s i.e. each specialist involved in the project executes their own individual element successfully and considers their involvement in the project complete once each stage has been signed off - E.g, A Test-Analyst executes their test scenarios, reports their findings with no major issues identified, receives sign off from stakeholders and then moves on.
But, is it really that simple?
IT project requirements are fluid and they can change at any stage throughout projects. We as testers need to transition an IT solution into production as smoothly as possible and deliver business benefits quickly. This emphasises the necessity for strong stakeholder management to ensure outstanding project delivery every time.
To ensure efficient project delivery, we need to understand:
- Who our stakeholders are
- Their individual roles and responsibilities
- Their expectations throughout a project
Project Stakeholders are the people who we will be working with on a daily basis primarily the Project Manager, Systems Analysts and Developers. The Business Stakeholders can be defined as the End Users - Senior Management/Sponsors and Business Analysts. Support Stakeholders are the Technical and Help Desk. The roles and responsibilities of these stakeholders will fundamentally remain the same for each project with subtle differences based on the methodology.
I will focus on the roles most applicable to us as testers. Let’s start with Project Stakeholders as these are the people who we work with most regularly:
Project Stakeholders
Project Manager
The Project Manager will be working closely with a Test Manager/Lead. They are responsible for the project schedule, budget and resource plan. They will liaise with the Test Manager to discuss whether there is a need to scale up the team in the case of any delays or additional functionality added to an already defined scope, or if the timelines have changed. By liaising with one another, it allows the Test Manager to revise the test schedule, resourcing or scope accordingly. If the Test Manager does not recognise the Project Manager as a key stakeholder, it is almost inevitable that the test delivery timescales will increase. During the test phase we are often still faced with making decisions about changes in project scope, build/defects prioritisation and new risks/issues (to name a few). The Project Manager needs to help pave a clear path through these changes to help the Test Manager focus on the key priorities, removing distractions which could derail the test delivery plan.
Developers
The relationship between testers and developers has been a topic for discussion in countless blogs over many years but it is important to remember that both areas share the common goal of delivering a system that works for the end users. There is a shared frustration when functional changes are requested late in the process as this could mean revisiting complete and verified code. It may also mean test deliverables need to be revised. The main clash between the teams in my experience tends to be how certain deliverables are realised. A developer may have addressed and resolved an issue presented to them and the tester may agree the requirement has been satisfied. However, he/she may believe the fix/change will create usability issues for end users. Issues such as this should be fixed prior to implementation, time permitting, to reduce the number of workarounds and change requests once in production.
Agile or Continuous Delivery methodologies introduce a number of subtle differences into the relationship between developers and testers. The scope of a release may change for numerous reasons, business decisions, lack of available development/testing time etc. There is also the possibility that individual items may need to be accepted into test on a piece meal basis and communication is very important so that testers know what can be tested and when. On the flipside the testers must notify developers of any issues so that they can be investigated.
Business Stakeholders
End Users
As a tester, when we think for whom the system/product is being delivered, it will be the end-user. This is because they will be using the software directly and regularly. To deliver something that would hamper their efforts or would create additional work to complete their daily tasks is exactly what we want to avoid for any software solution. This is why it is critical to utilise the knowledge and experience of end-users and have them involved early on. Being able to empathise with an end-user over existing problems they are having with a system and working towards reducing or eradicating these issues will give you a lot more credibility and support from the users and allow the delivery of a system that that they have helped to steer. It is the feeling of ownership and pride in the systems they have helped design that we are looking to instil.
Agile or Continuous Delivery methodologies introduces more focus in outlining what is being delivered, when and how it will work. Users working in different areas of a system will have different ideas on what improvement/fix(s) are more important than others but, clear and open communication in estimating and prioritising what will be deployed into the live system and when will help resolve this conflict. The assurance that issues are being actively worked on will generate confidence that the system will be improved and consequently make the users more productive.
Support Stakeholders
Technical and Help Desk
In many organisations, in my experience, the team making the software changes and those who support the Production environment are often different. Although both teams are ultimately driven by the needs of the customer locally they often have conflicting priorities – A Developer’s job is to make changes to the software however the support staff are required to deliver stability and predictability within the Production environment – change is disruptive!!
As testers it is critical we work closely with the support teams to provide assurance (through delivering the test plan) of the quality of the software before it moves into the Production Environment. Communication and collaboration throughout the test phase will help provide this assurance (if all goes well) or raise alarm bells (if all doesn’t). Either way, information is available to the support teams about the impact of the software changes and will inform decisions on the immediate and long term support requirements. Forewarned is forearmed.
Often overlooked during normal daily operations, this area is critical if you want to avoid the project team becoming a long-term support team. The implementation of changes to a legacy system when thrown ‘over the fence’, with little or no information provided to the support team can cause a number of problems. These problems could range from something common such as there may be a number of support pre-requisites missing to something more specific like a potential increase in call volumes
In order to avoid any problems, Support must be treated in the same way as the business stakeholders. It is up to the test function to ensure that members of the support teams are invited to attend walkthroughs and inspections prior to the software’s implementation to become familiar with the systems. The same goes for the development and operations teams, who should use time prior to implementation to allow knowledge transfer when possible which will save time and frustration before going live. All applicable service documentation should also be completed to the satisfaction of the support manager including details of all implementation items and any outstanding change requests or defects. Issues identified by the end-user post implementation reported to the Helpdesk must be shared with the Test Manager to be assessed and added to project backlogs for future resolution.
The above is true for both traditional and modern delivery approaches however, it must be made clear that support roles will never fully leave the project delivery teams. The aim however, is always to provide as much information as possible to minimise the number of queries that cannot be resolved by support which are subsequently passed onto the project teams.
So, back to the underlying question – is stakeholder management important in project delivery?
Simply put, yes. Although we are one part of the project team there must be synergy between all the stakeholders. How we handle these stakeholder interactions and what we achieve for each one, will have a direct effect on the quality of what is delivered at the end of the project in terms of functionally, budget and timescales.
Communication is key whatever delivery methodology is used, however communication becomes even more crucial when using an Agile or Continuous Delivery methodology. Here, there is a greater risk of change to what is being delivered and when as items can be removed or pushed back to future releases and new change requests or defects can be added to a projects scope at any time.
The important thing to remember is not to assume that communication has taken place and even more so, that expectations from all stakeholders are not allowed to deviate out of line with what will be delivered. We should fully understand the needs of each stakeholder and deliver to each individual’s expectations in a professional and transparent manner if the software solution is to be deemed a success both objectively and subjectively. Would you agree with this?
