Empirical conclusions after 5 months of profile work as a project manager in web application development.
I see this type of intermediate reporting “in front of myself” as the most correct method of increasing value for a specialist: a retrospective, a kind of “psychoanalysis” of one’s own activity, whatever.
I preface my story with a disclaimer: experienced managers or analysts – everyone who directly interacts with customers in business – this material may seem extremely useless. But for novice managers, the opposite is true.
Development is not the point
Piles of materials have already been written, of course, on the topic “does a manager need to understand the technical aspects of his work” – and your humble servant has such an article. Of course, it is necessary – but this is not a panacea, far from the main part in project management.
Joke. Interview of a managerial candidate in a technical company:
– What is the marker of successful completion of the project for you?
– Signed act of delivery of works.
Not to be such a manager from a joke – that’s the main thing. In such a comic form, I come to the only correct conclusion in my opinion: each member of the development team (or design, construction, marketing, and the list goes on) must bring value to the customer. This value does not stop at the ingenious knowledge of methodologies, business process debugging and the quality of the workspace (and in the case of my path and personal mistakes, the protectionism of the team and excessive emphasis on environmentally friendly communication and increased motivation) . This value lies in WHAT the customer receives. At the same time, all of the above, as if, goes without saying, and exists in the background.
People and interaction are more important than processes and tools.
Do you remember something like this? So: “people and interaction” is, among other things, “you and the customer” or “your team and customer“. So, let’s look at the conclusions.
So, I am publishing a list of 5 of my own conclusions based on completed and turbulent (and not so) projects under my leadership:
1. Immersion in the project manager and customer
It is necessary to understand that these are a priori different “entities”. The project manager and his team always know the inner workings: from the implemented functionality to the nuances of project management hidden from the customer. This means that we must take the side of the customer and try to see the gaps in our own demonstration materials and presentations, to see the level of uncertainty generated by usand not by the project itself or inconsistencies in the terms of reference, which cannot be avoided.
2. Scenarios over functionality
Whether you work in a “waterfall” format or in “flexibility” – there is no difference, you and the team are most likely to implement the functionality. Don’t forget that the client Always waiting to see scenario. The client sees his service as a set of screen forms or “features” that solve a business problem. Help him solve the business problem. This does not mean that you need to think about statistics and metrics – just show a basic understanding of the product approach and focus on the business you are helping.
3. Epic and user stories
We — managers, analysts, developers — think in the context of decomposition. We are trying to crush everything, chew. Sometimes we decompose not enough, sometimes we decompose too much. Find this balance yourself in the process of discussing the problem. There is a well-known rule – sometimes the performer needs to be given freedom of action and the opportunity to show creativity, sometimes – severely limited. It goes to show you never can tell.
4. Communication with the customer in the context of “sales”
As the head of my project office said: “The sale of the project does not end with the signing of the contract” – and I strongly agree with this. Demonstrating the results of your work is your responsibility, and the probability of failure is quite high here. Think of yourself as a sales manager as well. More experienced colleagues advise: if it is impossible to provide the results of the work, increase the amount of documentation and sent artifacts triple, record a screencast of your demo, constantly follow-up after your spoken conversations or even written dialogues. This, in all seriousness, can help you out.
5. Trying to find justice
Customers are people too, and they are not always right. Often, in dealing with difficult customers, I advocated the protectionism of myself and my team, practiced protection from insults, ambiguous hints, and sometimes even misogynistic jokes; courteously found out why business requirements have changed so much again, and to understand why we are doing everything “so wrong” in the understanding of the stakeholder – tried to “find justice”. It is important for everyone to go through this, to receive the necessary level of support and empathy from colleagues and loved ones in their direction. And then to understand that all this does not make sense. I do not expect patience and stoicism from the manager in all the roughness of our world, I just ask and conjure: do not imagine this as the result of managerial activity. You will lose more nerves and a coveted life-affirming “resource”. Subsequently, try to moderate your ardor on this topic and continue working – maybe already on another project, but with your own baggage of experience and “stuffed cones”. Whether you need it or not depends, by the way, on your character and temperament – people look at the world differently, don’t forget.