Author: János Szilágyi, PMP, Head of PMO at ApPello
Everyone’s agile… until they have to decide
“A well-paid administrator” -or- “the person who calls meetings”
This is how many refer disparagingly to the role of the project manager. It’s not easy to do the job, it’s a bit like being a football referee: they do the best job when the players think there was no need for them. Of course, the project manager has something to complain about, too. Players aren’t perfect either. The following is a subjective train of thought on the most common experiences.
You know the scenario, don’t you? If someone recognizes themselves, don’t get offended and don’t be ashamed. Ask any project manager where the greatest improvements need to be made in collaboration with clients and the top list would look something like this:
- client reaction time;
- allocation of responsibilities and intention to reach decisions;
- available capacity and expertise
All of these derive from a single source: honesty. A realistic and sober assessment of our true capabilities. When an indolent guy starts dating a fitness queen, he doesn’t necessarily become sporty himself… Nobody becomes agile by throwing about buzzwords like ‘tribe’ and ‘squad’ while members of the team cannot bear responsibility and don’t dare come to a decision.
In fact, a project manager is like an interface between the client (principal) and the service provider. His/her goal is to ensure that the service provider can hand over to the client a properly functioning product within the agreed deadline and cost effectively, who with this creates value for its own clients, not to mention the fact that it also makes money from the product. Meanwhile, the project manager diplomatically tiptoes around conflicting interests, trying to meet the needs of both sides, but in the interests of a project sometimes one or the other, or even both, must contradict. Things get even more difficult if the two parties, the principal and the service provider, have completely different organizational cultures. So we can best help his/her work if we honestly admit our organizational abilities and as principal don’t chase naive dreams.
Agility – ‘the emperor’s new clothes’?
Anybody with even the slightest experience in the world of project management will certainly have heard about the two main methodologies, the waterfall and the agile approach.
The waterfall model is a traditional approach where the goals, costs and resources are precisely defined at the beginning of the project. All the steps are highly structured and follow on in a pre-determined order. Furthermore, labour costs can be easily tracked and projected, which is reassuring for the principal. However, the reality is that the environment is always changing, problems and challenges are constantly arising, and these have to be adapted to in the course of the project. This gave rise to the agile methodology in the field of IT projects.
Being agile just means being able to react flexibly to a changing environment. Rapid reaction is more important than sticking to pre-determined plans. A functional end product also enjoys priority over comprehensive documentation. The emphasis is on people and not tools, the team is not structured hierarchically, rather responsibility is shared. The environment motivates creativity and encourages learning; the team leader manages more in the spirit of coaching. Agile project management is realized on the basis of iterations, that is it progresses step by step. After every step the team receives feedback and the principal can also keep progression of the project under constant monitoring. This is the perfect way of developing products such as a video game or a mobile app embedded into social media.
Well, representatives of the agile methodology, with all respect to the exceptions, often take on board only one or other concept from this: no need for documentation, no need for people who are responsible, there are no limits, nothing is fixed, go with the flow, there should be stand-ups… someone will always sort things out instead of us.
Rare as an agile big bank
Today, in the world of software developers, agility is a core value. But does everybody have to ride this wave? Is it possible for even a big bank to adopt this approach? The financial and banking sector is inundated with disruptive products and services, new technologies and modifications to legislation. In order to keep up with the fintech companies and neo-banks, the majority of banks have already started repositioning themselves towards agility. However, nobody expects anyone to proclaim victory prematurely. For example, a famous English bank set a timeframe of 15-17 years for agile transformation, and currently they are in the fifth year! The fact is that agility is not a method that is easy to acquire, it is far more a mindset. Most project managers experience that the client expects a high degree of agility from them and from the developer whereas the client, while professing themselves to be agile, are actually far from it. Smaller banks find it easier to start out on the path to agility but it is difficult to instil a major financial institution with the startup mentality. Nobody ever becomes agile playing table football.
I work in a waterfall and I’m proud of it
Every method has its advantages and disadvantages. When building a bridge, it is vital to know from the outset how the bridge, which connects points, is going to look. The processes follow each other in a very well-defined order. Responsibilities are precisely allocated, there is no such thing as ‘learning on the job’, there’s no room for ad-hoc creativity. The waterfall methodology is not a dirty word either. In itself, agility is not a guarantee of success. Nor are iterative projects purely agile projects, they often tend to be hybrid solutions which borrow elements from one method or another depending on the end product.
Acquire agility following the waterfall methodology!
More and more large institutes are hiving off projects, typically developments of innovative products, so that they can then be implemented in a quasi-startup environment with a dedicated team. A handy method for smaller apps is on-flight development: that is, products are tested in the early phase of development and the errors are fixed as the project progresses.
In the past few years Appello has built up considerable experience in what way it can best support the client in more effective collaboration. These will be explained in detail in the next post.