New Project, Different Pace - How To Adapt
New project, different pace – How to adapt
Have you ever moved projects thinking, “That last project was really difficult, surely the next one can’t be that hard” only to find the opposite?
As consultants, we move from one project to the next with open arms, looking forward to variety in the work we are to deliver and a change of working environment. What we sometimes forget is that every project is different and they all have their own challenges. Often we will go into a new project expecting things to be similar to where you have just come from; be it the management of the project, your level of responsibility, speed of delivery or even the hours you work. We are reminded quickly that no two projects are quite the same! It is how you take those past experiences and use them for the better that make us ‘great’ consultants.
For the better of the project, not yourself
Take the example of moving from a large, fast-paced project at one of the ‘Big Four’ banks to a much smaller project at a niche client. The projects may be similar in the way that they are both delivering an off-the-shelf product with their own added customisations. Whilst the end goal for both projects is the same – to deliver a quality technology product, on time and within budget – the road to achieving this goal may be immensely different, with its own turns and bumps along the way.
On a smaller project, many resources wear multiple hats and perform more than one role within the project team. Without the segregation of duties of larger projects, there is the tendency for people to be biased towards their own work and prioritise workloads by what they want to get done rather than what needs to be done for the good of the project. This can lead to time delays and bottlenecks, particularly when there are dependencies on one person delivering the work. Where there is functional segregation however, it can also lead to time delays due to hand-offs between teams rather than the one person being able to perform multiple roles. Each is a fine balance that needs to be managed appropriately to avoid delays.
In the larger organisation, these people may have been pressed to deliver given they have one specific role to perform. Instead on a smaller project, a level of diplomacy and understanding is needed to ensure people know their priorities and are not pulled in different directions. Put simply, something may be a priority for you, but not for the other person. People have different motivations in achieving a specific goal e.g. a Project Manager achieving a project milestone on time or a Business Analyst pushing a particular requirement through to the developers that we just don’t have time to incorporate. In the example of the Project Manager, this may be pressure that has come from top down so we need to be conscious of any time delays that may impact this milestone. In the example of the Business Analyst, any additions may impact development/test timelines, but if we don’t incorporate their changes, the product may not be fit for purpose so the appropriate impact analysis needs to be undertaken.
On a smaller project, many resources wear multiple hats and perform more than one role within the project team. Without the segregation of duties of larger projects, there is the tendency for people to be biased towards their own work and prioritise workloads by what they want to get done rather than what needs to be done for the good of the project. This can lead to time delays and bottlenecks, particularly when there are dependencies on one person delivering the work. Where there is functional segregation however, it can also lead to time delays due to hand-offs between teams rather than the one person being able to perform multiple roles. Each is a fine balance that needs to be managed appropriately to avoid delays.
In the larger organisation, these people may have been pressed to deliver given they have one specific role to perform. Instead on a smaller project, a level of diplomacy and understanding is needed to ensure people know their priorities and are not pulled in different directions. Put simply, something may be a priority for you, but not for the other person. People have different motivations in achieving a specific goal e.g. a Project Manager achieving a project milestone on time or a Business Analyst pushing a particular requirement through to the developers that we just don’t have time to incorporate. In the example of the Project Manager, this may be pressure that has come from top down so we need to be conscious of any time delays that may impact this milestone. In the example of the Business Analyst, any additions may impact development/test timelines, but if we don’t incorporate their changes, the product may not be fit for purpose so the appropriate impact analysis needs to be undertaken.
One of our consultants reported the adverse effects of conflicting priorities recently when a piece of work was required to be delivered by a business analyst in order for the test team to progress with their test build activity. Unfortunately, the work prioritisation was not managed correctly, resulting in the artefacts being delivered to the test team in a hurry before the product design and the process flow were fully understood. Once the design work was finalised, a large element of re-work to the test suite was required, which was in fact almost a total rework of the suite.
Simple changes, significant benefits
In the above example, had the whole solution been prioritised correctly, the business analyst could have finished the product design in sections and filtered through items as they were ready – a more agile and iterative approach – rather than having one deadline date. This would have vastly limited the downstream impacts on rework.
Although we need to treat each project differently, elements of previous projects may be introduced to a new project for the better. An example of this is the level of formality and governance. On a large-scale project, it isn’t really an option to bypass documenting your work as items are easily lost in translation or forgotten about altogether. A large project generally has a PMO team to manage documentation, governance, risks and so on, which means all items are tracked and kept up to date accordingly. On a smaller project however, if those ‘beer coaster’ requirements or that conversation over coffee is all we have to go off, as consultants, we can easily introduce simple learnings from previous engagements to improve the situation. These include measures such as formal tracking and change control.
This isn’t to make the smaller project the same as your previous project; it is about learning what works, identifying current pain points and applying learnings to the new environment. This can be as simple as sending an email following a conversation reiterating what was discussed and having those involved sign off on the email. These emails can then be tracked in a central location, so as to not lose sight of what was discussed and signed off. A simple and pragmatic way to improve governance and control.
Step back to move forward
We have found the best way to introduce improvements is to sit back and observe first in order to identify the pain points. Arriving with ‘all guns blazing’ and attempting to change things from the get-go may work in the odd instance but is more likely to rub people up the wrong way and lead to objection when suggesting changes in the future.
We need to approach each new project with open eyes, take a step back and observe while constantly being on the lookout for ways in which we can improve processes based on past experience. Use past learnings in a way that will help the project progress as a whole rather than meeting an individual goal. This will help people to take on the change positively and ultimately project you as a valuable member of the team.