The VOLO Guide to Project Management 

 

Self-Development

Just don't give up trying to do what you really want to do. Where there is love and inspiration, I don't think you can go wrong.
Ella Fitzgerald


Here in VOLO, Project Managers are passionate about their work. They don’t just want to be average in their profession, they want to strive for perfection. And the road to that is continuous self-development and personal growth.

Continuous development and learning play a central role in the daily life of a PM. This cycle of continuous improvement is expressed in the act of taking small steps towards a bigger goal every day, rather than trying to tackle everything at once.


selfdev

Sometimes though, taking these tiny repetitive steps can be boring and seem to be leading nowhere (hah, of course they will! How can we make judgments about something when trying it just for one day?!). However, several real-life examples we all have seen come to prove the opposite: it’s like climbing a ladder - you might even not start moving up if the steps are too big to start. Adding one field in the ticketing system that takes 2 minutes can reduce the number of questions and answers essentially. Having 15-minute daily stand-up meetings for sharing knowledge and making the work transparent will increase the team’s productivity and work efficiency. While it may seem that a 2-minute or a 15-minute effort will doesn’t make any difference, it really does!


devs

The journey of self-development does not end on the self only. In Volo, we take these steps that make the process complete (but not finished).



Self-Development


VOLO has a library of many valuable books - both technical and non-technical, from “how to code” to “become a successful leader,” and is always updated with new books. Believe us, it’s really difficult to take a book out for reading because the books are transferred from hand to hand extremely quickly. We always try to be up to date on the current changes in project management processes. This allows us to experiment with new approaches in our projects and make continuous improvements.



Team Development


Of course it’s great when project managers are professionals who know all nuances about their work. But it’s even better when the team has that knowledge too. And who should provide that knowledge to the team if not the Project Manager. We do not mean technical knowledge, but the one that Project Manager possesses - forming an Agile mindset, developing soft skills, using correct processes related to the applied framework, etc. Mini training sessions that last 1-2 hours are a great way to develop various non-technical skills in the team and coach them to become even better in their work.



Peer Development


Project Managers in VOLO have formed a PM community that is an alternative to the formal Project Management Office (PMO). This community is responsible for the standardization and improvement of Project Management processes and practices, as well as the development of the Agile Mindset and the correct application of Agile methodologies throughout the organization. Alongside these formal activities, the PM community also gathers once in a while to share ideas, discuss novelties in the sphere, reveal and solve pressing issues. We also share valuable books and other materials with so much enthusiasm as if a kid with a new toy!
All these processes become even more enjoyable considering the fact that here, in VOLO, team members, project managers, and others are not just employees of the same organization but colleagues and friends who will support each other at any minute!

Adaptive Leadership and Team Management

Adaptive leadership is the best visualisation of one of the 4 Agile values: individuals and interactions over processes and tools.

Managing projects to achieve their goals and objectives is challenging for project managers due to the complexities, risks they can face, and the nature of the projects. As research shows, many projects fail as a result of a poor leadership approach.

But what does it take to be a great leader? Is it charisma, decisiveness, wisdom, the ability to motivate people to follow you towards the project goal (when team members believe you possess all necessary skills and knowledge to get to the right place) or is it one heroic individual who single-handedly generates results by enforcing his will? Well, I guess we can agree the latter should not be accepted as the right answer, as leadership is now considered a team sport.

But it’s also difficult to highlight any other single trait that characterises a great leader. Rather it is a combination of different traits that can be adjusted depending on the specific circumstances and the goals to be achieved and problems to be solved.

This ability to understand that change is the only constant and that progress is often made of contradictory yet complementary trade-offs and that everything has its cost, is the main factor differentiating adaptive leaders from other forms of leadership.

Adaptive leaders should not only be open to changes themselves, but should also encourage their team members to adapt to changes, challenges, and issues confronting the project. Taking into account different types of team members, project leaders must change their style of leadership according to who they’re interfacing with. As leaders, we serve the team by adjusting our leadership style to meet team members’ changing needs, to lead each individual’s development within the team. That means that everybody shouldn’t be managed the same way. (Not to be confused with treating people differently. Project managers must treat every team member the same way in terms of showing respect, honesty, integrity). The way PMs manage and lead people should vary according to people’s needs, personality and behavior.

Adaptive leadership together with the team development processes can best be described by mapping Tuckman’s Model on Team Development and Situational Leadership Styles by Blanchard and Hersey. The application of those two models taking into consideration the concept of having self-managing teams, leads to the smooth formation and development of the team in any project.

The Tuckman Model defines 5 levels of team development.

tuckman

Based on these stages, we can map out leadership styles in the following format:



lead-table

We can outline the following characteristics adaptive leaders should possess:


  • Being able to relate project change to the primary values, goals and objectives of the stakeholders involved.

  • Being able to create an environment where all team members can freely express their opinions without fear of judgment or punishment and the ability to take advantage of such collective knowledge. Creation of such an atmosphere requires active engagement between the team leader and team members. The leader must control the interpersonal relationships by improving the social relations, clarifying roles, and solving interpersonal problems that the team may encounter.

  • Understanding that the change can be a painful process. Therefore, he or she can foresee and counteract any reluctant behavior from teammates.

  • Understanding that large-scale change is a gradual process, which calls for persistence and a willingness to bear the pressure that comes along with that.

  • Being proactive, looking for opportunities and investing the necessary resources to go after them.

  • Admitting when they make mistakes and changing or abandoning non-productive strategies.

  • Being open to experimentation and risk-taking.

  • Liking and encouraging innovation among employees.


Looking at all these characteristics, we can say that among the most powerful leadership tools are facilitation, coaching and training. It is through these tools/channels that adaptive leaders can stimulate constructive dialog between team members and keep their focus on a set of well-defined goals while moving through vulnerabilities during the project implementation.



Adaptive leadership is very attractive thanks to its contagious nature. It makes teams reflect the adaptive qualities practiced by the leader. As a team, they start to “play in unison” as if guided by an ace conductor. And the outcomes are significant results they create with great precision and the supportive environment they find within the team.



Adaptive vs Mechanical systems

The adaptive and mechanical systems in leadership are described in detail in the article “What is Adaptive Leadership” by Charles Albano.



adaptivevsmechanical

We cannot summarize the adaptive leadership and team management concept without talking about emotional intelligence, which is an integral skill of a leader.
Emotional intelligence is the ability to recognize and express one’s emotions appropriately, and to perceive and manage the emotions being expressed by others using observation, communication, and interpersonal skills. It enables a project manager to bring out the best in coworkers and team members by making them feel valued and important. To succeed in Emotional intelligence, a good project manager should concentrate not only on the project vision and final outcome, but the interpersonal relationship and individuals as well (again, let’s recall the Agile value we mentioned at the beginning). As a first step, the project manager should learn to recognize his/her emotions and control them, afterwards, influence the others’ emotions by inspiring them, developing, and facilitating teamwork and collaboration.

We should always focus on the team, the individuals, the working mood, and we will succeed as a leader and as a project manager. As one of the Agile principles states, “Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.”

Communication with Stakeholders

Project Managers spend nearly 90 % of their working time communicating. This includes not only discussions, but also reports, meetings, e-mail and other forms of communication. When hiring a person for the position of a Project Manager, recruiters focus not only on the technical and business skills, such as knowledge of frameworks, years of experience in the field, but also soft skills, namely – communication. It’s a known fact that the key to success in a project is well planned and well managed communication with stakeholders.

So, what are some PM oversights that result in less than successful communication with project stakeholders?


Lack of understanding of the audience’s communication needs:

Project Managers don’t analyze the needs of stakeholders throughout the communication process, which results in the “wrong message to wrong stakeholder” concept.



Lack of awareness of how the communication is received by the stakeholders:

Project Managers don’t feel the need to understand how the information was perceived, “I have provided the information, what else do they want from me?” They want to ensure they have understood your message correctly!



Lack of active listening skills:

When asking a question, Project Managers don’t bother to listen to the answer, as they’re too busy evaluating their own performance rather than the input from the stakeholders. This is why, “we should listen to understand” instead of “listening to respond”.



So, what does good communication with stakeholders mean to us? Is it a weekly report that is sent via email to all stakeholders each Friday at 3pm? Is it a proactive approach to the issues that may occur? Is it a daily call with the client to listen to his complaints and ideas? Or maybe a daily call to share your ideas about the process improvements?

Good communication is comprised of more than how the message is delivered. The information itself, the method used, and the timing at which it is delivered all contributes to effective communication.

Project Managers in VOLO highly value the communication with the stakeholders, and keep it transparent, accurate, and frequent.



communication


We focus on transparency. Thus, we provide the information to the stakeholders without filtering it – bad news should be communicated without any delays as well. But this doesn’t mean as soon as something happens, we inform the stakeholders. We are responsible for our actions, and if something happens, we first try to correct it by cooperating with the whole team. Only then do we inform the stakeholders about the issue and the actions we took to eliminate it. So, to reiterate, transparency in communication does not mean turning to the stakeholder the minute you become aware of an issue.


We focus on accuracy; we value the time of our stakeholders and do not go into prehistory before getting to the point. However, this does not mean we stick only to the official discussions. When the timing is right, we are relaxed and even make jokes when communicating with the stakeholders (but not too relaxed).


We focus on frequency, but within limits. We are expected to know our stakeholders and provide the necessary information before it is requested from us. We do not spam our stakeholders’ mailboxes with copious amounts of reports, long documents that, in reality, can be substituted by a 2-minute call. We create a communication schedule to keep it predictable and allow our stakeholders to schedule activities around the information received from such communication.



Communication is not about us. If we as Project Managers think one type of communication is better, it does not necessarily mean that it will be better for the specific stakeholder as well. And if we think that a piece of information is what the stakeholder needs, it, again, does not mean, they will actually need it. We analyze all needs and expectations, including the communication needs, of our stakeholders, and adjust our work accordingly, and periodically request feedback about the communication itself.

Effective communication leads to an effective stakeholder relationship. As Peter Drucker says, "The most important thing in communication is hearing what isn't said." We don’t simply listen to our stakeholders. We hear what they have to say, then monitor, analyze, and take actions accordingly. We provide solution options to their issues, instead of simply doing what they say. And by that we show empathy to our stakeholders, as we care not only about our job and our performance, but the success of their businesses.

If years ago, the term stakeholder management was used to describe this process, in today’s fast changing agile world it is more aptly described as a partnership (bordering on friendship). Team management, on the other hand, has evolved into servant leadership, stakeholder management has transformed into stakeholder engagement. The newer terms remove the hierarchical aspect from the corresponding relationships, making them closer to a partnership.
Adopting this approach brings balance in the communication between internal and external stakeholders and makes all of us act as one team. This is why we care about each other’s failures and successes, which paves the way to great results.

 

The Project Manager is Just a Team Member with More Responsibilities

In VOLO, the role of a Project Manager is critical in terms of leading our teams towards the project objectives. This role is clearly visible in all phases of the project. Project managers in Volo are involved in a project from its initiation through closure. Furthermore, depending on the needs of our customers, we involve project managers in the evaluation and analysis activities prior to project initiation. We participate in activities like consulting with executives and leaders of business units on ideas for advancing strategic objectives, improving organizational performance, or meeting customer needs. We have tailored project manager’s roles and responsibilities to fit correctly our customer needs and those of our teams. The list of these responsibilities is so long that we have decided to map them to the project management process group for ease of understanding.

understanding



Initiation

The Project Manager’s role in the initiation process group is critical, as this is the phase where the team structure is not clear, and resources are not yet assigned to the project. Therefore, Project Managers become the key contact point between the customer and our company. We are in charge of defining the main objectives of the project, its purpose, and its initial scope. Upon customer request, we provide a consultation on which project management tools to use. We then define the project lifecycle and project management methodology/framework. This phase is also very important in terms of identifying project stakeholders and defining a strategy for their efficient engagement.





Planning

The planning process group is a phase where PM skills and knowledge come in handy for all stakeholders for the sake of generating a reliable plan. In this phase, a project manager is a wizard who uses his or her magic tools, past experience and skills to create a plan that becomes the team’s bible to use in the execution phase. Depending on the project lifecycle, project planning can be done once for the entire project or spread throughout the project duration. Defining the correct planning phase and effort is one of the main decisions that the project managers have to make.

In VOLO, very rarely do we conduct the entire detailed planning of the project upfront. The complex platforms and software that we build changes and evolves so fast that having a detailed plan upfront is not realistic. We mostly spread out the planning throughout the project duration and adjust it with accordance to customer needs and the emergence of new knowledge and experience. We look at a plan, as a view to the future, but multiple views are possible, so we periodically adjust it for the sake of our customer’s competitive advantage.

So the responsibilities of PMs in this phase is to create a viable plan for our customer and for the execution team that will provide important insights into what direction we’ll be moving, which features will be included in the upcoming release, what the product roadmap is, and how we are going to get there. The Project Manager is also responsible for setting up the project management framework, selecting and configuring project management tools, defining development processes, setting up metrics for fair and reliable project performance evaluation and reporting and so much more…





Execution (Monitoring and Controlling)

Once the planning phase is all complete, and the definition of success is set, it is the time for executing it. How do we define success in the first place, and why is it necessary? When working in an agile environment it is important to define what we mean by a project’s “success”. The defining is usually done in the initiation phase and it may vary from project to project. For one, it could be a happy client with a great number of UAT-passed stories on his or her end, for another project success is achieved only when the software product reaches the end user and when that user feedback is positive.

Most of the time, the execution phase includes constant and continuous client feedback. Moreover, the continuous feedback from the business provides the development lifecycle with room for improvements in order to minimize the risk of failure and facilitate the eventual project success. We can conclude that the project could be called successful in case the project goal has been reached, the deadline has been met and, both the team and the client have achieved a positive outcome of a job well done.

Usually, the PM’s role in this phase is reflected through monitoring and controlling the overall progress towards the achievement of successful delivery and reporting it to the respective stakeholders. Besides, we protect the team from distractions, facilitate problem resolution, as well as lead the team into working through project changes. The Project Manager is the key person for assuring the smooth development process as well as managing time, quality, risks, issues within the framework of customer acceptance.

Within the scope of PM’s responsibilities, it is essential to consistently evaluate the process inputs and plans in order to deliver the output as per agreed specifications. Of course, things rarely go exactly as planned, which is why it is important to compare the actual performance against the planned one. In VOLO, we have created a set of project management metrics that help us to evaluate the team performance and create reliable reports that we present both to our customers and executives. More on that, in the Metrics / Project Performance Evaluation section.





Closing

Just as any other PM process, group closing is also highly important in the overall process flow. In this phase, we are responsible for the assurance of several components both for the stakeholders and the team: such as assuring that all work has been completed, all agreed upon project management processes have been executed, and getting recognition of an official sign-off form the client. Gauging the risk of a project not being closed as expected is also of vital importance, as it can cause various problems for the stakeholders and negatively affect team morale. This is why Project Manager is needed to make sure that the whole process has been completed and released within the framework of the agreed scope and time. After the project has been completed, a post-implementation review is often used to identify key lessons learned.




closing

Metrics / Project Performance Evaluation

  • Introduction

    Metrics are one of the touchiest subjects in project management for all project stakeholders. They provide important insights into productivity for different stages of the software development lifecycle as well as assist with the quality assessment of a product and track team performance.

    Unfortunately, when it comes to metrics, they are two extreme approaches:

    • The first is when hardly any data is tracked in a project. In these kinds of projects, it is impossible to tell whether the team is on track for the upcoming release or how the team can increase its efficiency as it moves forward as there is no data to compare.

    • The next extreme is when metrics and data are seen as a weapon to turn one team against another, developers against each other, or, worst of all, to justify overtime or mandatory weekend work.

    This is why most people have a love/hate relationship when it comes to metrics. But does it have to be this way?

    The answer is “absolutely not!”

    So how do you choose the best metrics that will give the interested parties reliable information about project and team performance without becoming a nightmare for the team? If you take into account only one metric, you just get tunnel vision. The team will try to improve only that metric, but that will not give you the big picture about the project health and team performance. The project can end up with a product that looks good but, in reality, is driving off a cliff. The opposite is not perfect as well. More is not necessarily better. Many metrics are considered as vanity metrics because they just make the team and the project manager look and feel good, but offer almost no actionable value. This only adds unnecessary bureaucracy, which is far from agile.

    In VOLO, we use agile metrics to reduce confusion and shine a light on the team's progress throughout the development cycle. The brilliant minds of the Project Management Office of VOLO came up with a set of metrics that provide cross checking and don’t end up becoming a headache neither for the team nor for the project manager. They provide important insight into the project health and team performance, and, at the same time, keep the team focused on actual work instead of worrying about some data. Based on those metrics, we generate a monthly report that we present to top management and to our client in order for them to keep a hand on the pulse of the project and reveal deviations and address them as soon as possible. We use only the metrics that provide us with actionable value for each of the project management frameworks that we have in VOLO.



  • Velocity velocity

    Velocity is one of the metrics that we use for Scrum projects. Besides being an indicator of team progress (what has been committed, what has been resolved), it is a very useful metric for the purpose of predictability. Using velocity backed up with historical data, we are able to communicate to our product owners how quickly a team can work through the backlog.

    However, in VOLO we do not treat velocity as an absolute measurement of a team's progress. It is an evolving indicator and changes with the team. For example, for new teams the velocity is expected to stabilize as soon as the team becomes more familiar with the project and with the work process, while for teams that already work with Scrum methodology, we treat velocity as a measure of consistent performance over time, and can confirm whether a particular process change was efficient or not. For such teams, a decrease in average velocity is usually a signal for the Scrum Master that some practices that the development team uses might not be efficient and should be brought up at the next retrospective.

    Another practice that we apply in VOLO while working with velocity over time with the same team, is constantly revisiting the team's estimation practices.



  • Sprint Burndown chart burndown

    The Development team also uses a Sprint Burndown Chart to track the performance of the team during the ongoing sprint. It is a graphic representation of the rate at which work is completed and how much work remains. The metric belongs to the development team, and it represents the team’s progress towards the Sprint Goal.



  • Throughput throughput

    Throughput is a Kanban metric which is based on the delivered data within a certain period of time. It is one of the methods to track the team performance over time. By tracking the throughput over time, it can directly show how your team’s overall performance is deviating from the previous period of time. Ideally, throughput should stay the same or increase – a decreasing throughput indicates that something is negatively affecting your team’s ability to deliver and will probably need a root cause analysis to understand what additional effort should be made to fix the existing issues.

    The unit of time that is taken to visualize the result provided by the team could be measured in days, weeks, months or even iterations. The swing between the results within few months or iterations helps us calculate and plan more accurately the job that is about the be started and visualize what the actual capacity of the team is, how it evolves over time, and what measures should be taken in order to achieve success within the framework of the next chapter of the work.



  • Cycle Time cycle

    Cycle time is a measurement intended to define how much time the development team has allocated from starting the development till its completion, or, otherwise, the handover stage to the client side. This metric mainly measures the speed of delivery of the product or service to the customer. A positive indicator for a team's performance measurement is cycle time reduction. One of the most direct and simple ways to reduce Cycle time is to reduce the waiting time of the process. In short, a positive indicator would be a stable or reduced cycle time average for the same period of time, which means that productivity of the team increases. On the other hand, it would be a red alert if we notice cycle time increase as its elongation shows that there are certain bottlenecks in the team or process management and that it should be taken into account and dealt with.

    One of the reasons why cycle time could be longer as compared to the previous month, for example, is the absence of a valuable team member during that period as he or she could be on a vacation. If, for instance, we only have 1 QA in the team, his or her absence could cause a bottleneck for the items to be checked and could be stuck in the process for as much time until he/she comes back to work. That is considered a blocker for pushing forward tickets to production and causing a cycle time increase.

    What type of message does this measurement metric pass on?

    • In terms of competitive advantage, it is better for an organization to have a shorter Cycle time compared to its competitor. That would indicate that the one who has a shorter cycle time will jump into the market quicker than the other and by that would gain higher preference of the product/service from end users.

    • Lesser Cycle time signifies higher efficiency and customer satisfaction

    • Cycle Time tells you how quickly your team can process a piece of work and you usually want it to be low.


  • Lead Time lead

    Compared to cycle time, Lead time Lead time shows us the time spent on the unit of work from the moment they have been requested by the customer until the moment it is completed. It is always longer than cycle time. Lead time describes two aspects of a system: the time it takes for work to be processed in that system (cycle time) and the time it takes for work to begin to be processed in that system.

    Lead Time tells you how you process work based on the number of requests coming into the system. It visualizes efficiency of the system. If you get your cycle time down you can push forward through your backlog faster which will then lead to customer satisfaction in terms of stories done.



  • Backlog backlog

    This metric is common both for Kanban and Scrum teams and is used by VOLO in order to have a global vision for the project. The number of tickets created in the backlog could indicate that besides the tasks that are being completed at the moment, there is a queue waiting for the team yet to be implemented. Practice has shown that the Backlog could contain both necessary and unnecessary tickets. There are several reasons why a certain ticket could become unnecessary. It could be due to market or business changes as well as system changes, etc. So, it is a must to review the Backlog once in a while in order to understand the relevance of the tasks as well as have a clear understanding of how much work we have and how long it’ll take. If the already updated and reviewed backlog increases once in a month, for example, that means that the requests from customers are increasing and that they prefer to continue working with the team. It also indicates the fact that the business needs are increasing. So, it’s a good sign.

    On the contrary, if we notice a decrease within the number of tickets in the backlog that could be an alerting sign for the team and the management that something is not going as planned within the business or the client itself. The reason could be different. It could be that there is not much demand from the market for that particular product/service which the platform provides, COVID-related slowdowns, etc.



  • Created/Resolved created

    This metric is introduced by the Atlassian Community and is widely used among Kanban and Scrum teams. The 'Created vs Resolved Issues' report is a difference chart showing the number of issues created vs number of issues resolved over a given period of time. The chart could be cumulative or not, it's up to you. The Created data shows how many tickets there are yet to be resolved by the team.And the resolved are considered those tickets which are already done by the team. The idea to compare these two indicators is also showing the team performance. So, if there are more issues created within a given period of time that it is resolved it means that the team is overloaded, or working too slow compared to the speed of upcoming work.

    If our created issues are less than the resolved ones, it indicates to us the following: the team is working faster than the market demands, and there might be inaccurate planning of resources. Doing the job faster than it's needed is not always a good thing. It means that the development team is often underloaded or doesn’t have anything to work on which can’t lead to an increase of efficiency and motivation of the team over time. This metric is a red alert for the business and to the project manager that the team doesn’t have an adequate workload. Another reason for having more tickets created than resolved could be connected to the system changes, for example, that are being pushed into the development process by the team, which generally freezes the business request stories from the client side. So, the business requests are created, but none of them are resolved due to a different work which is in progress.

    So, as you can tell by now, the ideal scenario is for created and resolved tickets to be created and resolved in parallel. The chart above shows us that there are as many tickets resolved as there had been created.

Process Tailoring

A client comes to VOLO for product development. After clarifying the points on project vision, high level requirements, milestones, the Project Manager to be assigned to that project analyzes this data and comes up with the project management approach to be applied on that project. In fact, what we do is process tailoring.

Process tailoring means adapting the agile methodology to better fit our project environment.

We have extensive knowledge of predictive and adaptive life cycles, we are professionals of Scrum, Kanban, XP, and other frameworks of Agile. However, these life cycles and frameworks cannot be applied to all projects equally, as they all have their advantages and disadvantages that may or may not hinder the smooth process of the project. The Project Manager’s job in the initiation stage should be to apply different criteria on the project and define the best possible approach for the project management. “One framework doesn’t fit all projects”. Moreover, e.g., even after applying Scrum to one of the projects, after some time we adjust it to our project needs to gain the best out of it!

At VOLO, we believe that a project management approach adjusted to the project needs is as important for the project success as the motivated and professional team and effective communication.

So, how do we do it and are we allowed to make changes in the frameworks that proved themselves efficient throughout the years?

One word: ShuHaRi

The concept of ShuHaRi comes from the Japanese Noh theatre, and it is a model used to illustrate the path an apprentice needs to take from the moment he or she expresses an interest to learn about something until that person becomes a master. In Agile, it describes an evolution in skills while implementing Agile methodologies and is a model for transitioning from one way of working to another. (Ivan, F. 2015)

So, let’s go deep into ShuHaRi and understand its meaning.

process

SHU - follow the rules:

As beginners, the team members start by following the rules learnt from the coaches. Of course, we can have an extensive knowledge of frameworks, however, when starting a new project, it all starts from the beginning - new team, new clients, new approaches… So, when starting a new project we come back to the step “SHU”. Speaking practically, we take the “Scrum Guide”, teach the team about the values and processes and follow each step to the tee.

HA - break the rules:

After mastering the rules, they become second nature to us, and we can start working intuitively. As time passes by, we learn the processes and we do not need the guide “to guide” us. We work subconsciously, i.e. we don’t focus our mind on the actions, we do it because it’s already our nature. Moreover, we also dare to change some processes, adjusting them to our project. Speaking practically, we switch on Teams at 10:00 AM each day for daily stand-up in the same way we brush our teeth each day.

RI - be the rules:

By reaching full mastery, we can excel and create new paths for others to follow. We are masters of the processes and we can even teach others. We incorporate some other processes that work best for us, thus “we create the rules.”

However, we cannot say that we complete the process tailoring on “RI”, as it is not considered the end; we enter into a loop of continuous improvement. The more we reach the step “RI”, the more knowledge we gain, the more we understand that there are a thousand times more things to learn to best tailor the processes and perfect our project management approaches.

And how to measure whether we succeeded in choosing the best approach possible for the project?

  • The clients are happy with the way of working with us and will cooperate with us again.

  • The team would love to work in the same way for other projects as well.

  • The project is handed within time and budget, and the scope perfectly incorporates the project vision defined earlier.

Don’t think that these criteria are too simple to measure the success. Believe me, if you receive such feedback, you and your team have succeeded in that project!

Project Management: Expectations vs Reality

pm

One of the beauties of the project manager profession is its endless mystery. Some people think of project managers as superheroes who can do anything, while others find this profession as an unnecessary overhead cost.

Much like in those popular memes, your friends think that all you do is hang out with your customer and team and chat your day away. Your team thinks that you are just booking rooms and scheduling meetings and constantly getting in the way of their work. You mom thinks that what you do is travel, attend international summits and save the world by fighting climate change, poverty and hunger.

So who are Project Managers after all? There are many myths about these mythical creatures, and here are a couple of them.


Myth 1

There is no such thing as Project Management qualification/formal education.


This is a big one!
No toddler has ever uttered the phrase “When I grow up, I want to be a Project Manager.” Many people think that no one really wants to become a project manager; they just end up stumbling upon this profession by accident or under strenuous circumstances. Some people have no idea about whether there are institutions of higher education that offer courses in this discipline. Or rather, is it a discipline after all? Isn’t it enough to be fluent in a foreign language and be good at communication to become a project manager?

This is not entirely false. The notions take root in the historical evidence of the formation of this profession. No one actually considered project management an actual job before the 1940s even though the first project of the Great Pyramids dates back to 2500 century BC. In the 1960s and 1970s, most project managers were “accidental project managers”. The accidental project manager was born and has lived in the folklore of business projects for more than a generation (Bourne 2005).

So who were these “accidental project managers”? They were individuals who were leading projects just because they were available and willing to, not because they had any project management expertise, technical knowledge or skills. Evidently, some of these “accidental project managers” were remarkably successful. Nevertheless, most of them found themselves being blamed for problems and project failures they were ill equipped to predict or prevent. After all, their careers and qualifications were in another discipline, and it was normal because those people ended up in that position by “accident”.

Starting from the late twentieth century, however, the world witnessed the emergence of the qualified Project Manager. All project management associations, worldwide, mobilized their forces to codify project management knowledge, created examinations and certifications of project managers based on a defined knowledge framework. In fact, many universities and colleges nowadays offer project management courses. Qualified and professional Project Managers rose and shined heralding the emergence of this new profession. A full-fledged profession!

Myth 2

PMs control everything.


There is a common belief that project managers are control freaks. Most people think that the project managers’ main concern and main job is about making sure everyone is at their desk at 9:00 sharp and leaves only after 18:00. The later the better! If people go to lunch, they can leave their desks for no more than 1 hour.

These misconceptions become especially evident when new junior members join the team. They feel that they have to ask the project manager if they could leave 4 minutes early. Or, they apologize for being 6 minutes late. The most amusing thing is they feel that they have to provide a meaningful explanation why they were late.

The truth is that we are NOT control freaks. We care about discipline, it is important for us not to be late on Daily Standup meetings. But we are not some employee time tracking software. Our job is very simple. It is about bringing control to uncertain, complex, shifting and sometimes confusing environments. Most of our methods and tools are designed to help us do that. As long as the job gets done on time and on budget, the customer is satisfied, we don’t care who was late for 6 minutes. We are there not to monitor the work but to be the driver of it. We just want to maintain a healthy pulse on our projects. That is all!

Myth 3

Scheduling meetings and overseeing tasks is the ONLY thing that the PM does.


Ouch! This is a common misconception, perhaps because of the more public-facing part of the PM role that involves developing project plans, coordinating meeting schedules, providing seemingly countless status updates, and compiling meeting notes. It's widely known that the PM is the one person who is always against multitasking; however, the truth is that he/she is the one who constantly multitasks throughout the day.

The real value of a good Project Manager is in the value he or she adds to meetings and negotiations, or else the one who is not involved in those meetings at all. Though this sounds like a joke, it's not entirely untrue. A big part of a PM’s job is to be a mentor and counselor to other team members - a process that is often called coaching the team. This means that a PM doesn’t simply schedule meetings, set deadlines, define discussion scopes, and cares only that his formal tasks are ticked off. Sending a few emails and drafting some reports are a part of project managers’ day-to-day job which frankly speaking is either done in between of everything else or when the working day has long ended.The reality behind a successful organizational process is that a PM provides the team and, when necessary, the stakeholders with a comfort area where people can freely express opinions and make appropriate decisions, thereby making sure that the discussions are productive and that all the parties are on the same page.

We can even say that the project manager is the project champion – they go to bat for team members and stakeholders both and work to make sure the project is a success. Moreover, PMs spend more time communicating with other people including team members, external and internal stakeholders, than they do “pushing deadlines.”

In other words, your role as a PM involves project vision, the accurate and on time delivery of the project, tasks management as well as the roles and responsibilities of the team. It is way much more than just paperwork.

Myth 4

PMs are all about the Agile Methodology.


When kicking off a new project, people often ask themselves which is better: agile or the traditional waterfall? The truth is, both methodologies have their own strengths and weaknesses.

There is no good or bad methodology. It is only by understanding the project requirements will you be able to determine which methodology to adopt. Satisfying the client is indeed the foremost important thing, but if the team also wants to feel satisfied and accomplished in the process, it should build a software solution that works both from the client’s and the development team’s perspective. That’s why it is vital to choose the best methodology not only based on best practices, but also by considering the success of the collaboration between the team and the customer.

So, does this mean that choosing and setting methodology is all that the PM should participate in? The answer is a bold no! By choosing a framework we do not define exactly how it should work in the process. It is difficult, persistent work making sure that the framework is actually doable and is working at its best both for the team and the client. Also, we need to keep in mind that changing the plan along the road is not bad news. On the contrary, responding to changes could be beneficial in terms of market changes for the client as well as for the team's professional growth and motivation.

Myth 5

We don’t need a PM. We can manage everything by ourselves.


There is a common myth that Project Managers are often considered to be a bottleneck both for both the clients and the team. On one hand, from a client's point of view, the PM is someone who is not letting them push forward with their own timeline. The PM is considered an obstacle on the way of getting directly in touch with the developers. In other words, the PM is a headache you need to come to terms with and keep in the loop with regards to every decision. On the other hand, the team thinks it has the burden of unnecessarily reporting and updating someone on a regular basis.

Sounds annoying, right? So, if all of that is true, why do we need PMs and what value do they actually bring anything to the table?

While there’s certainly some meeting scheduling and overseeing involved, project management is definitely more than that. With a big picture point of view, the project manager balances and guides their team members, while defining project requirements and goals to ensure the team executes tasks on time and on scope. The development team always feels on the safe side when they know they have a go-to person. This also concerns those team members who you think most probably will deal with everything in the project and won’t need anyone on the side to help. But that’s not always the case.

The client also feels content knowing that they have a single point of contact - a designated person whom they can contact, communicate any issue, and know that the development team is safe and sound under their umbrella.

Without all of the above it could be the start of a never-ending chaos within the team, product, project, and become an issue between team-clients relationships. The PM is the one who smoothes everything out all the time and brings the team and the client together. And without it, who is left to navigate through the ups and downs, clashes and catastrophes of projects?

Great project management means much more than keeping project management’s iron triangle in check - delivering on time, budget, and scope. It unites clients and teams, creates a vision for a successful project and gets everyone on the same page of what’s needed to stay on track for success. When projects are managed properly, there’s a positive impact that reverberates beyond its delivery.

Myth 6

The project manager must be a subject matter expert.


People who don’t work in the IT industry often ask if it is necessary for Project Managers to have subject matter knowledge. No doubt, having a technical background as well as maintaining all of the soft and managerial skills is definitely a plus. But is it necessary? Absolutely not!

One of the benefits of not having code level knowledge while working with coders is that the PM is able to keep the big picture at the top of his/her mind instead of digging into the details. Delving into details for PMs is unnecessary and sometimes even destructive. In other words, without subject matter knowledge, the PM is less likely to get too preoccupied with over perfecting the product or service, which could lead to adding on to the load of the team, changing the scope and priorities.

As already mentioned, quite a lot of time is spent on communication not just with the team but also with internal and external stakeholders including clients and management, who don’t often have broad knowledge of the subject matter. So, it becomes necessary to report to them in plain, business-oriented language rather than code level technical one.

What is also important to understand for a project manager is that even though he or she doesn’t need to understand every issue on a code level, they should be able to perceive certain project specific high level technical knowledge. This will help them not only grow professionally but also be on the same page with developers and adjust their knowledge and practices with management processes more easily and professionally. For sure, this is a huge plus both for the team and the clients, especially if the client side consists of tech-oriented guys. While all of this may sound unattainable, it isn’t. Everything comes with hard work and experience in the field.

Myth 7

All conflicts should be solved by Project Managers.


Those who think that project managers are superheroes, also think that all conflicts should be resolved by project managers. Of course, project managers are professional cat herders. That is, when people run in different directions with different drivers or intentions, conflicts become unavoidable. A project manager’s role is to make everyone look in the same direction and follow the common goal resolving any conflicts that come across. However, project managers are not miracle workers. Even though they are experts in conflict resolution, sometimes there are conflicts that project managers alone cannot overcome. In those cases, external mediation may be required.



Conclusion:

To summarize, there are many misconceptions about the profession of the Project Manager. Some of them have some historical origins while others are just out of lack of knowledge. Certainly, a project manager’s job is not straightforward. You cannot explain it in one sentence. That is the reason why there are so many myths and beliefs about the role of these new age leaders. That's because the job of a PM depends a lot on the involved parties both internal and external. So one of the most important skills that you need to possess as a Project Manager is the ability to be flexible and why not - agile. However the diversity of this role makes it what it is now - simply AWESOME .





References:

  • Burt, S. (2019). The art of listening in coaching and mentoring. Routledge.
  • Crowe, A. (2006). Alpha project managers: What the top 2% know that everyone else does not.
  • Rohan, D. (2020). Adaptive Leadership Strategies and Project Success of Construction Project Managers in Jamaica [Doctoral dissertation].
  • Albano, C. (2007). What is Adaptive Leadership? Self Growth. http://www.selfgrowth.com/articles/calbano.html
  • Wood, M. (2007). The Yin and Yang of Adaptive Leadership.
  • Hersey, P., Blanchard, K. H., & Johnson, D. E. (2001). Management of organizational behavior: Leading human resources. Pearson College Division.
  • Goleman, D. (2009). Emotional intelligence: Why it can matter more than IQ. A&C Black.
  • Tuckman, B. W. (1965). Developmental sequence in small groups. Psychological Bulletin, 63(6), 384-399. https://doi.org/10.1037/h0022100
  • Bourne, L. (2010). The future of the hero project manager. Paper presented at PMI® Global Congress 2010—EMEA, Milan, Italy. Newtown Square, PA: Project Management Institute.
  • Ivan, F. (2015). Becoming agile with ShuHaRi. Paper presented at PMI® Global Congress 2015—EMEA, London, England. Newtown Square, PA: Project Management Institute.

Transform your business with Volo

Thank you for contacting us!

Our team will be in touch with you shortly.

Oops!

Something went wrong

try again
WE’RE HIRING
landscape

Please rotate your device

This page is best viewed in portait orientation.