Tampere
23 May, Thursday
9° C

The library of essays of Proakatemia

Project Management



Kirjoittanut: Thais Santos Araujo - tiimistä SYNTRE.

Esseen tyyppi: Akateeminen essee / 3 esseepistettä.
Esseen arvioitu lukuaika on 13 minuuttia.

Written by Seungyeon Shin, Juho Helin, and Thais Araujo.

 

1 INTRODUCTION

 

According to the Project Management Institute (PMI), a globally recognized authority in the project management field, some key techniques for leading a project include developing a project plan that includes clear goals, timelines, resources management, building and managing a project team that has the right skills and expertise, communicating effectively with stakeholders and team members, monitoring and controlling the project status to ensure it stays on track, and adapting to changes as they arise and making necessary adjustments to the project plan (Dionisio 2017, 2-4). 

 

PMI has a book called Project Management Book of Knowledge (PMBOK). PMBOK is not a methodology itself, but it is an excellent guide with principles for general project management. However, we do have very known and useful methodologies in the market: waterfall, agile, scrum, kanban, scrumban, adaptive project framework (APF), lean, critical path etc (TeamWork 2022).

 

Knowing the size of the company and the length of the project are essential information to decide which methodology to go ahead with. Collecting this information before selecting the appropriate tool is crucial, as each project management technique is fitted to suit specific cases, and therefore, choosing the right tool can significantly enhance project outcomes. 

 

With a global population of approximately 8 billion people (Worldometers 2023), it’s unlikely that only a single technique for leading a project will be universally applicable across all cultures, project requirements, deadlines, and team contexts. The complexity and diversity of projects require a tailored approach that considers the unique circumstances and variables involved in that specific project case. 

 

Here is a description do two of the methodologies mentioned previously: waterfall and agile. The contrast between these two option are make clear the possibilities and correct fit can be very different.

 

Waterfall is a more traditional framework to organize a project. It works just as the title. In the beginning of the project the requirements and expectations are settle and development follows a linear scheduled sequence. This methodology can be a dangerous option in many project cases because it doesn’t allow room for changes and unexpected obstacles along the way. 

 

Agile Methodology is a project management framework that has been extensively been used in the software development ecosystems. It happens due to the dynamics and flexibility of the tool. Agile breaks projects into multiple phases and allows continuous development which is normally very handy for the developers and the clients in a software development environment (Laoyan 2022).

 

Risk management, is often forgotten or not taken seriously in the beginning and along with the project. Independently of the methodology chosen for a project, risk management is a significant and powerful tool to avoid delays and to be prepared for unexpected internal and external happenings. It is such an important tool that it is possible to get an ISO 31000 for risk management. A free brochure with the expected standards of successful risk management aspects is available on their website for download. A complete version of the “Risk management — Guidelines” presents a complete overview of why, what and how things do around the topic (ISO 2018).  

 

The project manager and project leader, it is quite hard to point out the difference between them. It sounds similar and the roles between them seem interchangeable, however, it is important to understand the difference for better management and development of a project. (Collazo 2021) Project leadership goes beyond project management. If the project managers are more of a technician who require skills for problem-solving, effective functioning of a project and managing stakeholders, project leaders are so to say generalists. (Collazo 2021)

 

2 PROJECT MANAGER AND PROJECT LEADER

Specifically, in project management, it is vital to be rational, logical, and analytical. Analyzing facts, calculating timelines, and making rational decisions is vital. Therefore, it is task orientated, focusing on delivering customers’ requests within a determined time, cost, and quality. These skills mentioned are excellent for managing tasks, especially if they are needed for larger projects. But what about building a high-performance team and great interpersonal relationships with stakeholders? As tasks are important, people are important as well. Without good-quality people, it is hard to lead a project well. Likewise, project leadership that requires creativity, vision, empathy, and personal connection is necessary. (Madsen 2022)

 

Madsen highlights the difference between management and leadership when it comes to motivating people and teams, to achieve their goals and objectives. Leaders are taking a pull approach by aligning individual objectives to one of the projects on an individual level to get the best out of people. Leaders make people follow, and that is how it is described as a pull approach. However, managers take a push approach, assigning tasks and instructing based on what should be done. The direction is going for the manager to people. We need to manage the tasks and lead the people. (Madsen 2022)

PICTURE 1. Management vs Leadership (Horine 2005)

 

So, where is project leadership needed? The table helps to understand the question. There are different aspects of project leadership, and it can be provided by different managers and leaders depending on project areas, which means that the project manager is not the only provider of project leadership.

 

Table1. Project Leadership Areas

 

What are the effective ways to lead a project? Among 12 keys to better project leadership, this essay will go through 5 keys: People-orientated, visualizing the goal, facilitating progress, compensating for weaknesses, and lastly, showcasing self-control.

 

  1. As it is mentioned above, project leadership is more people-focused compared to project management. Taking a holistic approach that puts people first, it brings more authentic relationships with each stakeholder.

 

  1. Visualizing goals and providing direction to the team is a basic aspect of leadership, however more importantly, project leaders have to see the end and make people aware of it as well.

 

  1. How to accomplish project objectives, how to get to the end successfully, and making it as easy as possible are one of the most important jobs of a project leader. Facilitating progress includes having the structure, process, and tools for a team, and actively solving the issues by quickly anticipating, confronting, and resolving them.

 

  1. Recognizing own weaknesses and having enough self-awareness is important for a project leader to team work effectively. Someone’s weakness can be someone else’s’strengthes and utilizing this starts from the project leader’s weaknesses.

 

  1. Emotionally stable and consistent in their behaviors is key for a project leader. Remaining calm under the circumstances of stress and pressure is needed.

 

Although many key factors to effective project leadership were mentioned, one simple mindset called “Servant leadership” might be the most powerful for successful leadership. Servant leadership is about putting “service first” than “me first”. Horine explains that this approach is the best way to do the right work in the right way with the right people.

 

In specific, servant leadership takes a strong service-oriented approach that emphasizes listening, responsiveness, and patience. It keeps the interest of others by asking for input and feedback from all stakeholders which eventually leads to growth and improvement in all team members and the organization. It also promotes the ethical use of power, as it influences and persuades people with the use of skills, not by manipulating them.

 

The Best Leading Practices

 

Independently of the different aspects a project can have, project leaders must be flexible and adapt to changing circumstances and team dynamics to ensure project success. Not only flexibility and adaptability, but also have willingness to learn and improve a long the way are excellent characteristics achieving success in project management. 

 

Modern leadership tries to focus on being a leader and not a boss. Fostering a culture of trust and transparency has a positive impact on daily interactions and product outcomes. This is possible by building a relationship with subordinates based in respect, taking the time to listen to their concerns, and being transparent in the communication. The consequence of this effort is a feeling of union and trust between the work community (Abrashoff, 2012). By now, it is already expected that a team that trust and work as an unity doesn’t only deliver high performance results, but also enjoys to work together.

 

“It’s Your Ship” is a leadership book written by Captain D. Michael Abrashoff, a retired US Navy officer who turned around the performance of the USS Benfold, a guided missile destroyer. In the book Abrashoff highlights the culture of trust as said before, and also other great leadership practical advices for a successful leader. The book includes the following points worth of taken in consideration while leading a team:

 

  1. Take ownership of your ship: Abrashoff argues that leaders should take ownership of their responsibilities and empower their subordinates to take ownership of their tasks as well. This creates a sense of ownership and responsibility that leads to better performance and morale.
  2. Communicate clearly: Leaders should communicate clearly and effectively to ensure that everyone is on the same page. This includes setting clear goals, providing clear instructions, and giving feedback.
  3. Encourage innovation: Leaders should encourage innovation by giving their subordinates the freedom to try new things and take risks. This creates a culture of innovation and continuous improvement.
  4. Focus on the mission: Leaders should focus on the mission and the goals of the organization, and align their actions with those goals. This creates a sense of purpose and direction that leads to better performance and morale.

 

Abrashoff’s leadership style is based on empowering subordinates. In the book focusing on the mission would be focusing on the project or on the organization someone would be leading. By following the principles, leaders can create an organization of high-performance that are capable of achieving its goals (Abrashoff  2013).

 

3 SPRINT PLANNING AND USER STORIES

Understanding sprint planning methodology and story system gives you the tools for project management. Although these are most used in software development, they can still be applied to any other project which needs management methodologies. Sprint planning sessions are events where the team gathers and plans tasks to do for a set period of time (usually two weeks) How to have effective planning sessions is explored in the following text. Another topic covered is writing stories instead of tasks. One of the benefits they offer is getting into the mind of a customer and thinking like them. How to utilize stories efficiently is also explored.

3.1 Sprint planning

The sprint is a set period where all the work is done. However, before you can leap into action you have to set up the sprint. You need to decide on how long the time box is going to be, the sprint goal, and where you’re going to start with. The sprint planning session kicks off the sprint by setting the agenda and focus. If done correctly, it also creates an environment where the team is motivated, challenged, and can be successful. Bad sprint plans can derail the team by setting unrealistic expectations. (West)

The time for sprint planning is usually set to be two hours, during which all the necessary things for the sprint must have been decided.

3.2 Negotiations

Sprint session can be seen as an acted-out negotiation between at least two characters. The product owner who is the one trying to negotiate the most value he can get. The development team who are the ones trying to negotiate the effort they are going to put in towards the sprint.

Whenever the owner suggests a task on the sprint which brings in value, the development team counters with the level of effort they are willing/capable of putting towards that task.

This play is acted out until a consensus is found, which leads to a creation of a sprint plan which brings in the most value and is realistic to achieve, based on the willingness and capacity of the development team.

If the developers forget their roles as negotiators and try to appease the product owner, this leads to unrealistic sprint goals which are not met. A practical tip for developers to use is crossing your arms during negotiations. Such a physical act might help defend against a pressuring product owner. Both parties need to understand that developers only have a certain amount of effort they are willing and capable to put in, they need to be honest and transparent about that effort.

The product owner should not have authority over development, neither the development team should have authority over development team. This ensures that sprint planning stay as negotiations.

It would make sense that consultancy services usually have a lot better sprint planning sessions, as opposed to inhouse employees. This would make sense because they are much more of negotiations.

The Inputs – A great starting point for the sprint plan is the product backlog as it provides a list of ‘stuff’ that could potentially be part of the current sprint. The team should also look at the existing work done in the increment and have a view to capacity. (West)

Product backlog is a list of tasks that need to be done for the sprint. Before the sprint planning session there should already be a list of these tasks, usually described in a single sentence, and more clearly defined during the actual sprint planning session.

Each task is written in a specific way which makes them stories, what stories are will be described more in depth in an upcoming chapter.

The What – The product owner describes the objective (or goal) of the sprint and what backlog items contribute to that goal. The scrum team decides what can be done in the coming sprint and what they will do during the sprint to make that happen. (West)

The product owner is the one defining the sprint goal, while the developers negotiate what is realistic with the effort that they are willing to put in. Couple of good questions to ask the product owner include “How do you imagine the situation after two weeks” and “Why do we want to accomplish our goal”

Making sure there is a shared understanding on what the task is important. This is accomplished by asking. A good trick to use is after explaining a task to someone, have them repeat it back to you. This will help you understand exactly how the other person has comprehended the task.

The How – The development team plans the work necessary to deliver the sprint goal. Ultimately, the resulting sprint plan is a negotiation between the development team and product owner based on value and effort. (West)

The product owner should always be arguing the value which the customers/end users will get. The product owner should want all the possible value they can get. The development team need to defend against such crazy value demands with reality.

Developers should always remember that it is far better to under promise and overdeliver, rather than overpromise and underdeliver. Personally, I have always found my tendency is to overpromise because of my agreeable personality.

Once the what has been established, you can answer the how you will get there question. In practice this means negotiation on who does what and which order are the tasks done in.

Task priotisation is important, but sometimes tends to turn into a chaos in sprint planning, where each task is categorized as very important. To prevent this, you can ask the product owner to define the single most important task and the single least important task of the sprint.

The Outputs – The most important outcome for the sprint planning meeting is that the team can describe the goal of the sprint and how it will start working toward that goal. This is made visible in the sprint backlog. (West)

The whole team should be able to describe the outputs which you generate. It is also imperative that everyone in the team is honest about their skill level. Some tasks might exceed teammates skill level and he/she might be hesitant to admit it. To prevent such incidents, you need to generate an

atmosphere of trust within the team. This is done by admitting when you are wrong or when you don’t know.

Not knowing something is different from being vague. Don’t ignore the unknowns, they are the reality of doing difficult work. But don’t hide them by using vague words. Instead, be clear when you don’t know something and frame the work in terms of gaining an understanding. (West)

3.3 User stories

A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer. (Rehkopf)

The tasks which make up the backlog are called stories. They are called stories because thinking of tasks as stories helps thinking like the user.

Stories use non-technical language to provide context for the development team and their efforts. After reading a user story, the team knows why they are building, what they’re building, and what value it creates. (Rehkopf n.d.)

Stories should use non-technical language, understandable by non-developers. A good tip is having a non-technical person involved during sprint planning to see if the stories are understandable.

Developers should understand the value they are creating, a common problem for developers is that they tend to not think like end users. This causes them to focus on things which end users do not care about.

Stories keep the focus on the user – A to-do list keeps the team focused on tasks that need to be checked off, but a collection of stories keeps the team focused on solving problems for real users.(Rehkopf)

Solving problems for people is infinitely more rewarding than solving a problem for the sake of problem solving. Seeing the positive impact on the world gives your work meaning, which is fuel for motivation. Stories help you see the real-world impact of your work.

Stories enable collaboration – With the end goal defined, the team can work together to decide how best to serve the user and meet that goal. (Rehkopf)

Stories are a quick way to see an end goal. Writing task specifications takes ages, and you often do not know what goal you are trying to reach. Writing a short story of an end user who has a problem which gets solved is a fast way to come up with a goal to reach.

During a sprint or iteration planning meeting, the team decides what stories they’ll tackle that sprint. Teams now discuss the requirements and functionality that each user story requires. This is an opportunity to get technical and creative in the team’s implementation of the story. Once agreed upon, these requirements are added to the story. (Rehkopf)

Another common step in this meeting is to score the stories based on their complexity or time to completion. Teams use t-shirt sizes, the Fibonacci sequence, or planning poker to make proper estimations. A story should be sized to complete in one sprint, so as the team specs each story, they make sure to break up stories that will go over that completion horizon. (Rehkopf)

Making time estimations is bad because everyone perceives time differently, and it is such a complex measurement.

The unit of measurement does not really matter, the point is that you use something simple which everyone knows.

Once the team learns to better utilize the measurement system, you can roughly estimate for example how many XL or XS stories the team can accomplish during one sprint.

Definition of “done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is. (Rehkopf)

A good way to achieve this is having everyone explain their own definition of done, while the leader documents it. Then the leader spends some time in contemplation, emerging with an amalgamated definition of done which he presents to the team. This definition is then continuously refined during each sprint.

User personas — For whom? If there are multiple end users, consider making multiple stories. (Rehkopf)

If there are multiple things the user wants, you can create a single user story and substories which happen to personas involved. If you have seen Pulp Fiction then I bet you enjoy the following example. As Marcellus Wallace, I want to hire two goons to get my briefcase back from the thieves, so that I can have my soul back which the briefcase contains.

This story could be defined to branch out into two substories describing the goon’s motivations. As Jules I want to fetch the briefcase, so that Marcellus Wallace pays me the reward money, which I use to help the poor.

As Vincent I want to fetch the briefcase so that I get the reward money, which I will use to buy drugs for myself.

As Marvin, I will help out Jules and Vincent by revealing the location of the thieves hideout, so that they won’t kill me.

It is optimal to get motivation of each persona. Creation a branching people for all the people involved will explicitly state the motivation for each persona.

“As a [persona], I [want to], [so that].”

It is optimal to get motivation of each persona. Creation a branching people for all the people involved will explicitly state the motivation for each persona. Using this as a framework when writing stories helps answering three important questions: who is the persona, what does he want and why (persona + need + purpose)

 

4 CONCLUSION

The essay gave the writers understanding and the tools for project management through learning about different methodologies in project management, it. Gaining deeper understanding about project leadership, sprint planning, and user stories will be useful in our future projects.

References

Collazo, J. 2021. Five differences between a project manager and a project leader. Read on 03.03.2023.https://www.forbes.com/sites/forbesbusinesscouncil/2021/06/03/five-differences-between-a-project-manager-and-a-project-leader/?sh=31024a696a14

 

ISO 31000. 2018. Risk management. Read on 1 March 2023.

https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100426.pdf

 

Laoyan, S. 2022. What is Agile methodology? Read on 1 March 2023. https://asana.com/resources/agile-methodology 

 

Madsen, S. 2022. What are the differences between management and leadership- and how does it relate to PMs? Read on 03.03.2023. https://www.susannemadsen.co.uk/blog/what-is-the-difference-between-management-and-leadership-and-how-does-it-relate-to-project-managers

 

Project Management Institute, 2021. Project Management Body of Knowledge (PMBOK) Guide.  Read on 1 March 2023. https://www.pmi.org/pmbok-guide-standards/foundational/pmbok 

 

Rehkopf, M.User stories with examples and a template. Read on 15.03.2023.https://www.atlassian.com/agile/project-management/user-stories 

 

TeamWork. 2022. Which project management methodologies should you use? Read on 1 March 2023.

https://www.teamwork.com/project-management-guide/project-management-methodologies/

 

West, D. Sprint planning. Read on 15.03.2023. https://www.atlassian.com/agile/scrum/sprint-planning

 

WorldMeters. 2022. Current World Population. Read on 1 March 2023. https://www.worldometers.info/world-population/ 

Post a Comment