Search results

Answers on this issue may diverge. According to PMBOK, project is a method that creates a unique product, service or result, which has a clear beginning and end. But do we always initiate create a change via project? And is change management the same as project management? Do every project creates a change? The answers to the question posed can be varied. It all depends on how you look at it. If we talk about how a project is defined and we pay attention to the fact that each project is an event that creates unique content, in which case it could mean that each project implements a change because it introduces something new. However, if the project is related to the modernization of processes and their atomization? Can this be considered as a change? Yes and no. If we talk from groups of people who will be affected by the result of the project, for them it will be a change, because the implemented results, for them, can change the routine of how they worked and have to work now after the automation of the process. But if we look from the side of the result of the project: the process remained the same, just some of the steps were digitalized, but whether this can be considered as a very unique change is probably not very much, unless changes in the process fundamentally change the principles of work and established rules. Exactly the same situation would be if we were talking about upgrading IT system. The main elements of the system do not change, but with updates, the interface of the system often changes, some buttons appear or disappear, data upload channels, etc. All this, for people who have to work with this IT system, can be, in a sense, a change that requires people to be prepared, trained. So, whether the project is equal to a change - that it all depends on how we look: in many cases, for people who will have to work with the product, service or new result introduced by the project, it will be a change, to which people will have to adapt and learn how to work. When comparing from how the product itself or the services for which the project is initiated change, not always the result of the project will be like a change, since it may simply be the management of certain technical depts., but the system or product itself does not fundamentally change. Is change management the same as project management? I think project management and change management is not the same thing. Project management is just a way to implement new solutions or improvements to existing solutions. Meanwhile, change management (not IT change management, i.e. not according to ITIL) is about how people accept the new result of the project and what actions to take so that people would have a necessary buy - in. In short, project management and change management are interlinked, but not the same. Poor management of change can lead to the fact that the result of the project will not be so positively received by the people who have to work with it. However, this will not necessarily affect the outcome of the project itself, but can harm the way in which the project is viewed in the eyes of stakeholders.

Lately, everyone as if they have agreed between themselves, are asking me about the maturity of project management in the organization. So the question is, what is basically the maturity of project management? How is it measured? Is it measured? When we talk about the maturity of a process or methodology, what project management basically is, it can be measured easily enough by self-assessment: what level of documentation is ready: is there only process guidelines prepared? Or is there a complete description of the process ready? The most detailed step is - instructions - is it implemented? how long does the process exist? This question helps to assess whether the process has passed the adaptation phase, during which the steps of the process described in the document are adapted to real situations that may not have been foreseen by the creators of the process how is the process introduced to people who have newly joined the organization? Do they learn from the instructions? Are they assigned a mentor who tells about the steps of the process (this part is very related to the knowledge management, but we will touch it next time)? How are changes in the process presented to people? How is the proper level of knowledge maintained over the course of the year? does the process have the standard templates and tools to perform various steps? is there a role of the process owner? ... and many other questions that must be thought through when trying to decide whether existing process or practice is mature enough. However, when we talk about the maturity of project management practices, a very important element is the understanding of which cycle the organization is in and in what environment the organization operates. Why is this important? The answer is very simple when we are looking from the practical point of view. Project management guidelines in a newly established organization may indicate that at the current stage of the organization- lifecycle, the practice of project management is at the level that is needed. In the same way, if an organization is stable, constantly growing and functioning, for some time and let's say it only has project management guidelines for 5 years - this may indicate that the practice is too weak for this type of organization and over the time it can become one of the obstacles to successful growth. When we try to compare ourselves to others, or whether we are strong in the field of project management, let's not forget that the environment in which we operate is always important.

After reading the PMBOK book or Prince materials that teach project management methodology, it may seem that projects are only those that have a very clear scope, duration and budget (you've probably heard of the iron triangle?). And all this is true, if you want the project to be successful, it is important that you have a clear vision of what you want to achieve. However, this does not stop you from experimenting before choosing a vision that you want to implement during the project. First of all, let's start with what is an experiment in project management? Experimentation in project management to me is simply an opportunity to test many different hypotheses, theories or IT solutions before making a decision on which one to go with. In IT project management, one way to test different theories is by creating demo versions of the solution, i.e. prototyping a future solution and thereby deciding whether it is what you want to achieve. In non-IT project management, experiments can be carried out by selecting and testing a target group, lets say process changes. In a sense, an experiment can be treated like a project as well, as the steps are very similar to those used in general project management practices, but it is usually treated as the ideation stage of a project. When deciding to conduct an experiment, there are, first and foremost: the hypotheses that we want to check or test are listed - an analogy to the idea phase of project management it is assessed how the hypotheses will be tested: creating a solution prototype, testing after forming a target group of people, etc. - corresponding to the project planning phase a hypothesis study is carried out - the project implementation phase a decision is made according to the obtained research results, which way to go, or maybe not to develop the idea at all - project closing phase, including user acceptance phase The only difference between normal projects and experiments is that after the experiment, the answer is obtained, which vision of the idea is more suitable for the organisation and only then the real project is initiated, while after the implementation of the project, an already working solution or product is obtained. For this reason, it is not uncommon for organisations to discourage experimentation, as it requires investment and may not necessarily yield results. Although, in principle, experiments cost less than such situations when in the middle of the project it is understood that the chosen solution will not bring so much benefit and the direction needs to be changed. Therefore, it is recommended to allocate some amount per year for experiments in the organisation, because it encourages people to think out of the box and reduces the fear of making mistakes.

There are plenty of places where it is mentioned that project management includes stakeholder management and communication management. If these parts are not given enough attention, there is a 99% chance that the project will fail. However, what I very often notice is that these two topics are approached in a very technical way: there are a bunch of different methodologies on how to evaluate and rank different stakeholders (about this in another blog article:)) or what kind of information, to what size of audience, via what communication channel should be communicated. What I really miss is the emphasis on the fact that the project team needs to invest in relations with stakeholders. One of the most important elements for project manager success is good relationship with stakeholders. The expression investment in the relationship sounds very sophisticated. However, these are simply some extra steps to create a sincere relationship with the people whom you need to achieve a common result with. And to a very large extent, project managers forget about it. I will give a very real example: in the workplace, just a few tables away, there is a project manager and one of the people who is an important part of the project team to make the project successful. Both of these people are in the same remote meeting and are dealing with all kinds of problems that the project is facing at that time. What happens during the call is that the same person who is sitting very close to the project manager expresses his opinion, that project manager does not do enough. Meanwhile, one of the observers, who sees the situation, is surprised how they behave and why they don't solve such things separately by simply running to each other's tables. After analyzing the situation, it is very clear to me that, unfortunately, in this situation, the project manager did not put extra effort into the relationship, so that there was no confrontation. And possibly he himself behaved in a similar way. Relationships are a two-way street: if you do not treat someone correctly, then it will boomerang back. It is important that project managers put a necessary effort to avoid potential disputes with stakeholders. Returning to the situation itself, what could have been done to prevent internal dispute from occurring? In such cases, when I already feel that there is friction: I try to talk to the person and discuss together how we can improve our cooperation. It is not easy because you have to get over your ego and we are all egoists in one way or another next step: when you come to the office, don't forget to say hello - we often forget that, because everyone is on their phones and headphones - to hear someone say good morning to everyone - an ancient history these days and finally, in a difficult situation you should go and ask for help in a very simple and human way: not with letters, not with assigned tasks and a directive tone, but just to go and say: please help, because the project is not going well This doesn't mean you have to become best friends with everyone, but these small steps often help clear the clouds on the project team relationship front. Final thoughts. When it comes to project management, relationship management is one of the key elements for project success. Even if project was delivered on time, within the budget, does not mean, that stakeholders will see project manager as the one they will be willing to work next time. You do not need to become best friends, but you should look for angles and build your connection around it, that are important to your stakeholder the very least.

A PMO is part of the project management methodology and in organizations where project management principles are applied, you will find this type of team - perhaps not with such a specific name all the time, but function for sure. What is interesting is that PMO can be translated in different ways: Project Management Office, Program Management Office, Portfolio Management Office. The translation of the PMO has a lot of influence, what you can ask of this group of people. Bellow your will some thoughts of what are the differences between those different type of teams: The differences listed above could go on and on, but in my opinion, these are the main points to consider when deciding what your team will be called and what their functions will be. Of course, it is worth noting that the organization should create such a team as per its needs, i.e. what benefits the organization would like to achieve by having such a function.

Team work, collaboration, team player, everybody is in the same boat - all these words and more describe collective work, that is discussed in various team workshops. Question is how we notice such example from company leaders? If we want others to act as a team does not matter where in project team or just across the organisation to achieve common goals, we leaders, need to show it and work with our peers accordingly. Easy to say, hard to achieve... Why most of the time, such behaviour among leaders is observed very rarely? What are the artefacts that would help to encourage our leaders to work as is they would feel being in one boat? This is what i have observed and would like to share: Unfortunately there are not many leaders who are interested to achieve company goals just for common good. Normally this intention is visible when leaders have invested in the company, for example their have company stocks or their own and their division results are heavily dependent on the overall company results (from what i have observed it should not be lower than 35% from all annual kpi's), but still keeping organisation modular setup in-tacked: organisations are made up of parts that have considerable autonomy, even while being somehow connected Another important element is how leadership team is constructed and wether it reflects company situation in the market. Possible roles among leadership member are: "hunters" and "farmers": Hunters - push for diverging discussions & "wild ideas" and bridges these and initiatives through common values and big - picture goals Farmers - push for efficiency gains and execution, connects the performance focus to the current mission and times

Most probably you have noticed that every year we have some new IT solutions and technology unicorns are popping up all over the world. But does it mean that ways of working are changing in IT project management as well? There are new tools that are established for more efficient IT project management definitely, but the theory is not changing that much - it just deepens. I think during the lifetime we just uncover the areas where all existing widely described project management methods could be used and how big range of applicability there is - and i am not talking about waterfall only, same is for agile methodology. The one thing that is not changing, that we are stepping on the same stones still when it comes to practical implementation of various methods in actual work, not spending enough time on diagnostics of how other companies implemented processes in different areas taking into account the culture they operate in.

There are so many training, that try to tell, of who is a leader or who can be them. But have you ever though who is a leader to you in the organisation? The way how i think about the leadership, may sound like a cliche, but leader to me is a person that loves, understands and cares about the area that he is responsible for. You not to be a boss or manager to be a leader. Everybody can be a leader in the area that they are working in. The only few things that i am looking for in the leaders are: honesty with others - dishonesty is smelled from a mile respect - do not think that others are not as good as you are, because that is not true and other people are not agreeing with you not because they do not understand what you are communicating, but rather because they have a different experience, different perspective invested - is present and performs the role to it's fullest, but not to get the check understanding of his / her weaknesses - is not over confident who thinks that knows everything in the world, though sometimes he / she is just getting started and invests in improving standing with their decisions - do not hide behind somebody who made a decision and says, that this is something, that he / she does not support though the decision was made and could not do much good hearing - listens and analyses of why people are against changes or things that you want to push forward and invests time to explain why chosen way is the best way and what different opportunities were considered ability to make a decision - there is a good practice when you ask around your people what is the best way forward, but final decision needs to be done by the leader and definitely not by voting, because you loose sense of ownership then

Have you ever noticed that we often jump into conclusions on why some of the people do not support the change that you are driving? How to see that? Well only practice makes perfect. While studying masters in university, i have chosen to write a work and do the survey about employees cynicism towards changes in organisation. Who have ever though that it will be useful for me in the future? I did not, for sure ... Talking about one of the reason why people tend to be less supportive to the changes in the organisation that i have uncovered decade ago in my masters thesis, was related to the amount of years that people were working in the organisation: the longer person works in the same position to the same employee the less belief he/she has that anything can be changed or improved, because of the fact, that all organisations live in repeating cycles. So here you need to find arguments of why this time this particular change will work. "Period of how long person is in the company, competence, power and motivation - these are the things that may help you to understand your stakeholders better" Another important element to understand your stakeholders is their motivation - why they would or would not like the change to happen. You need to be very careful by attaching the reasoning of why some of people are against of what you are proposing: it is better to have somebody that you trust, help you to assess your stakeholders and your evaluation. My recent mistake was that i have jumped to the conclusion too fast, by assuming that this would impact employees integrity in the organisation, because change would mean that the way of working that was established by the same person would be discontinued. After some of the deep dive and thinking on my own, i actually understood that there are different reasons to that: person did not trust me - it is two way street - i did not trust that person as well, so since we felt it from both sides, we were basically doomed to not hear each other person was thinking that the issues that i am trying to solve are the issues that only i see, though there was analysis done across the organisation - lesson learned - i realised that i did not actually show the results of the survey to that exact person When you are thinking about your stakeholders and trying to understand who is the resistor and who will support you, do not forget competence element - different competences may determine of how the change maybe be understood by these people. And finally not to forget - power: the more powerful person is, the bigger support or resistance you can get. We are talking not only about the power granted by the role or the chair that person is sitting from hierarchy point of view - there are informal leaders that can spread the good word (or bad) about the change that is about to happen.

There are several delivery methods, that organisations, can choose to do: waterfall, agile and hybrid. How to know which one is the best for you? If you would like to deliver things Waterfall, these are the things to consider: a list of business requirements must be provided before starting the project if people will be partially dedicated to the project team, agree very clearly on the percentage of time they will have to devote to the project activities assess the level of project manager maturity (sometimes projects are also managed by product managers, so it is very important to understand the level of progress) to manage the project, it will be clear what level of project control is needed understand the maturity of the project management process, depending on how often and where the verification activities are required answer the question of who will make the decisions related to the project and what level of decisions will be given to whom (this also applies to the Agile method) .... Well, and of course, the tools for project management - what do you have and what do you need? #projectmanagement #lessonslearned #project #sharingiscaring #knowledgeispower #changemanagement #ismoktospamokos #projektuvaldymas #pokyciovaldymas

There are several delivery methods, that organisations, can choose to do: waterfall, agile and hybrid. How to know which one is the best for you? If you would like to deliver things Agile way, these are the things that organisation and your team should have: you should have stable team, where people know each other, because in Agile you need even more discipline than in Waterfall, because of the pace that deliveries are being delivered your team should know Agile basics and there should be a product owner that knows how to run such a team in such a manner there should be a product roadmap with clear minimum viable products listed in the timeline the team should have tools ready which should help to keep communication flowing via well set process workflows (this one often forgotten) - for now Jira is the best tool for that What are the things to think about for Waterfall? Please find it in the other post Part2. #projectmanagement #lessonslearned #project #sharingiscaring #knowledgeispower #changemanagement #ismoktospamokos #projektuvaldymas #pokyciovaldymas

Nowadays you hear that companies have chosen to do the deliveries Agile way of working, because this allows to be faster to the market. In essence it is true - Agile methodology gives an opportunity to deliver things faster. But have ever thought whether all projects can be run in certain way? I have seen some of the organisations, that declare about going fully Agile, though in reality not all the projects can be done Agile way of working. Why? Key reason for that is that not all projects can be split into minimal viable products, that you could or would make sense to deliver in iterations or sprints. Projects that you should consider delivering in traditional or waterfall way are purely infrastructure and regulatory requirements projects, that normally have one delivery that needs to be delivered as a whole to achieve necessary value. There is no point to setup one server if two are necessary, right? Or to setup up one reporting field, when whole report is needed. Obviously Waterfall does not say, that you can not deliver projects in phases, by setting up project plan according to deliveries that you need to achieve, if they can be developed in sequence. This way most of the time is used due to resource limitations and if there is enough time to do the deliveries on time. #projectmanagement #lessonslearned #project #sharingiscaring #knowledgeispower #changemanagement #ismoktospamokos #projektuvaldymas #pokyciovaldymas