The VOLO Guide to Project Management

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.

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!

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 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.

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

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.

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.”

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?

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 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.

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.

• 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 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

  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 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 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

  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

  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

  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.

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.

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!

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.

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 .