When an architect draws up a building plan, they have to lay out all specifications in advance, and those can’t be deviated from at a later stage. You can’t just lay the foundation first and then contemplate how many storeys you want to build, five or twelve. Otherwise, the entire project can quite literally collapse.
In IT, things are exactly the opposite. Yes, at the start of a project, we develop the terms of reference and create prototypes, but everything can change during the actual implementation; for instance, the client may start providing a new service which will require us to create a separate section on the website. So in IT, you never truly know what’s around the corner when it comes to project management.
Project manager is the person in charge of the whole thing from the first meeting with the client all the way to the project handover. His responsibilities include:
- Customer communication
- Project flow and budget planning
- Task assignment
- Implementation control
- Project acceptance and handover
All of these processes largely depend on the choice of project management methodology. And this is where the uncertainty begins, as it’s hard to predict in advance which method will work best.
Choice of methodology
There are many different approaches to project management, but the most common ones are Waterfall and Agile. Even though Agile originally emerged as a standalone methodology, it has become sort of an umbrella term for all flexible models that differ from the traditional Waterfall type, such as scrum, kanban, scrumban, etc.
The Waterfall methodology is a classic management model with a linear sequence of stages, where one follows the other in a cascade (hence the name). This approach involves a pre-defined list of tasks that should not change significantly during implementation. In other words, everything goes according to plan.
At Toimi, we use Waterfall for standard projects with a fixed budget where the list of tasks and the approximate deadlines are more or less clear right from the get-go; for instance, this is the case with online stores and service catalogues.
However, large and unconventional projects are very difficult to predict in advance. In such cases, it’s best to use more flexible methods where the content of each stage can vary from month to month. That is, while we are working on one set of tasks (in scrum, this is called “sprint”), we are simultaneously discussing the timing and content of the next sprint. In the traditional scrum approach, each sprint lasts two weeks, but in reality companies often form their own deadlines based on the workload.
This approach offers more flexibility and enables you to adapt to external factors. For example, if the client wants to launch a delivery service as we work on their website, all they need to do is prioritise this task. This way we will start working on the service during the very next sprint, not some six months after all other stages have been completed.
In addition, flexible project management methodologies are great for projects with a long authorisation process. This is relevant for large companies, where every change needs to be approved by a whole range of executives. In the traditional model, this process can stretch over a long period of time, but with the flexible approach you can work on one set of tasks while simultaneously discussing the next stage.
Negotiation
In many cases, the choice of project management methodology depends on the client. If the client is IT savvy and is deeply involved in the project, they can participate in process management and task prioritisation, i.e. work under an agile model. But companies often request fixed rates, which implies the traditional approach. There’s usually a good reason for that: the head manager has to report to shareholders or the CEO and plan the budget. And since the contractor cannot insist on a different methodology, the two parties have to figure out the most optimal solutions together.
In project management, communication with the customer generally requires good negotiation skills from the manager. The client’s vision of the project is usually very different from how the technical team sees it. The client cares about the results, budget, sales and leads, whereas the dev team needs a clear set of tasks. And it’s up to the project manager to bring these two visions together. His goal is not to impose his viewpoint, but to find common ground and help understand the project’s value, allowing the parties to seek out the best possible solutions.