The nature of digital requires a unique approach to managing projects. We need to embrace new working practices if we want to see success.
I work with a lot of digital teams in a lot of different organisations. Teams struggling to deliver projects to unrealistic deadlines and with too few people. Yet with all the external pressure placed upon them, sometimes they are their own worst enemy. Too often their approach to running projects is not appropriate in the digital field.
With depressing regularity I see the same mistakes made time and again. In this post I want to share 10 of the mistakes I see. 10 practices that work against the nature of the web instead of embracing it.
1. No clear process for prioritising incoming work
Many digital teams work on an ad hoc basis. They have no clear process for prioritising incoming work. This was fine in the early days of digital when demand from colleagues was low. But today every part of the organisation has digital projects they want built. Most in-house teams have more work than they can undertake. They have to choose what to prioritise.
Unfortunately, few teams seem to have a clear idea how they prioritise projects. Instead they focus on the projects from the loudest or most senior members of staff. The appropriateness of the project is a secondary consideration.
Every team needs a clear policy. A policy for deciding which projects receive their attention and which have to wait.
2. Working on too many simultaneous projects
Some teams avoid the problem of prioritising by attempting to work on all projects at the same time. To placate stakeholders they juggle projects and try to keep them all moving forward.
Every time I see this the result is the same. Progress is far slower than addressing one project at a time. This is because team members struggled to switch back-and-forth. Developers in particular find this challenging.
The best digital teams work through a stack of projects one at a time. If the teams are large they break themselves down into smaller groups. This allows them to work on more than a single project with each group owning a project. But each smaller group only handles one project at the time.
3. A lack of collaboration
Part of the reason teams think they can run many projects is because they see projects as linear. They attempt to “manufacture” digital solutions on a “factory line”. They hand projects off between team members. The designer does her work and then hands on to the developer and so on.
But in practice, digital projects do not work like that. They need a continual back and forth between team members. They need close collaboration and cooperation.
The result is that projects bounce back and forth, slowing everything down. For example if the developer needs the designer to make some amendments to the design, he has to wait. Wait until the designer has time free from the next project the project manager has given her.
That is why project teams work better. It allows the team to work collaboratively, moving through the project together. Yes it may lead to some team members being less busy in some parts of the project. But generally projects will progress faster.
4. Inappropriate tool selection
Often the tools we select to manage projects can reinforce wrong thinking. For example most project management software encourages factory line thinking. But managing the time of a digital team is more fluid than that.
The team structure I outlined above means that some team members will have downtime. You need to be aware of that and adapt to accommodate it.
That is why I like Float, the people sponsoring this post. They have designed their app to accommodate a more fluid working environments. It makes adapting to changing circumstances easy. That encourages a more flexible working approach. One better suited to digital projects.
Of course inappropriate tools don’t only apply to project management. Designers who work in software that forces them to select a fixed canvas size is another example. This does not support the dynamic nature of the web.
Picking the right tool for the job is so important. Tools designed for how we work, rather than tools that force us to work in a particular way.
5. An unhealthy focus on specifications
Too many of the digital projects have the odds stacked against them from day one. They begin with a long specification laying out exactly what the team should be building. Specifications that are inappropriate for several reasons:
- They are not based on user needs.
- They are not researched for appropriateness.
- They become inflexible documents. Documents that do not accommodate lessons learned in the project.
- Stakeholders can read them in many ways. This can cause confusion and misunderstanding.
- They are often a wish list of functionality that leads to over engineered solutions.
- They are time consuming to produce. This slows down the delivery of the project.
Specifications made sense on projects where the cost of change was high. But digital allows us to adapt as new information arises. It also allows us to gather far more data than other mediums. Data that can inform our direction.
6. Failing to do your research
Of course, we can even improve a specification if we have enough information from the outset. Yet many teams seem to skip over a discovery phase because of the pressure to deliver.
Once again this is a false economy. Take the time to understand business requirements and user needs upfront. This will avoid costly mistakes further down the line:
- It will avoid building things users don’t actually want.
- It will ensure you discover hidden dependancies and related projects.
- It will unearth stakeholders who might derail the project at a later date.
- It will help define what success looks like.
Upfront research does not need to be onerous. A focus group with users and a workshop with stakeholders can often be enough. Even one day of discovery upfront will make all the difference. Time that you will save in costly mistakes during the project.
7. Far too much debate
I am always seeing projects grinding to a halt because two stakeholders disagree. Hours wasted arguing over how to solve a specific problem. That or something trivial like the choice of colour.
This problem is particularly irritating because it is so easy to solve. Whenever a disagreement occurs, test. Mockup the alternative approaches and test them with real users.
Yes, mocking up a solution takes time. But you will waste more time if there is a culture where people resolve these issues through debate. Not to mention the negative impact it has on the team dynamic.
8. No clarity over roles
Part of the reason projects get mired in debate is because there is confusion over roles. People become defensive when they feel their toes are being trodden on. The trouble is few take the time to define roles upfront.
Many stakeholders don’t understand what expectations the digital team have of them. This leads to them expressing their personal opinions. They will also suggest solutions when the problem is best left to the professionals.
To resolve this issue define the role of colleagues at the outset. Focus them on identifying problems, not providing solutions. Problems with how your solution meets business requirements and user needs. Make it clear that it then falls to you to solve the problems they identify. This simple conversation makes projects run much smoother.
9. A lack of clear decision making
The problem with roles also extends to who has authority to make the final decision.
This is especially true in projects with many stakeholders. But even a straightforward project with a single client can prove problematic. That client might not be the final decision maker. They may have a manager into whom they report. Somebody who could “swoop and poop” on the project at a later date.
If this is the case, it is important to include that manager in the project. Failing that, get the manager to defer authority to somebody else. Get them to relinquish their right to comment on the project once they have delegated.
If there are many stakeholders, consider a responsibility assignment matrix. This will ensure everybody is clear about how much of a say they have in the project.
10. No agreed working methodology
Finally, few teams I encounter have established and communicated clear working methodologies. In other words, there is no formalised process.
These teams do have working practices. They are just not formalised and communicated to clients. This means the teams are always having to justify their approach. Often they find themselves working in ways they are unhappy with.
It is so important to formalise a teams approach. You can do this by creating a service manual or set of design principles. An approach agreed and supported by senior management. An approach that you can enforce if required. But an approach that you can also communicate to stakeholders at the start of the project.
Many more issues
As with all such posts it is suspicious that there are exactly 10 items. In reality I have seen many more. That is because so few teams feel they have the time to sit down and think these things through. Instead they stagger from one project to the next, doing what they have always done.
But the truth is they cannot afford not to find the time. That they waste so much time and energy working in ways that are far from efficient. In ways that undermine the project, their reputation and the profitability of the business.
Float is the fast and friendly resource scheduling app that helps you keep track of who's working on what and when.