The management world we are living in is constantly evolving. New frameworks, new methodologies are invented, re-invented and adapted in order to satisfy the need of a very dynamic market. Every time something new appears, first we fight against it and after its value it"s proved by some pioneers we are ready to make that thing the new religion for us.
The same thing happened with Waterfall, the same thing happened with Scrum, the same thing is starting to happen with Kanban. Businesses are evolving also at high speed and the frameworks which allow fast adaptation and fast delivery where caught in what we like to call the Agile concept, the most en vogue syntax in the IT domain for some years now. With all these frameworks around, managers can easily fall into the trap of complacency and forget about basics. The basics of project management are well defined, well structured and in my opinion, despite of what many people believe, knowing and evolving into a structured information doesn"t step into the agile rules. On the contrary, the knowledge can be adapted and can be a powerful tool into juggling with Agile frameworks.
As many others in this area, my evolution to project management has gone from development to technical leading and finally turned into management. I was lucky to follow a basic project management training but, most of the good stuff was learned on the way. For sure, the process wasn"t lean and it had its ups and downs. There were moments when I struggled and there were moments when I struggled more. But those were the moments which paid off later. Slowly the struggles decreased in time and there were more and more "I know this" moments. And it seems that this is what the specialists are calling "experience". And once we feel that we are gaining more and more experience, we are so happy about it that sometimes we feel the urge to put a stamp on it. And that"s the moment when we are usually looking for a certification. And that was also for me the moment when I started to get more interested in what PMI and PMP means. Just to be clear, I am not writing this because I want to advertise for PMI, far from me, I didn"t apply to get my certification yet. It is a goal for this year and all I did until now is to follow the training needed as contact hours in order to be allowed to register for the exam. I am writing this because during that training, and also in other discussions related to PMP certification, the main debate between lots of people was: "How does this apply to agile? This has nothing to do with it". As we were able to see in my opening, I think the knowledge that you need to have in order to get the PMP is an awesome asset (and in the same time a must) for every project manager in the Agile world.
PMI certification is about structured information, a lot of documentation and a clear path on how to manage a project to its completion (not only in IT). The guidelines for this are caught in a big book called PMBok. Agile is not about tons of documentation, it is not about a clear path and rules set in stone but the end result is the same: completing a project. I will try to make a case for my point of view in relation to Scrum because this is where I have the most experience. Scrum framework defines some roles which are not normally retrieved in the general Project Management theory, like the Scrum Master role. Scrum Master is the super hero who owns the process and who needs to solve all the impediments so that the team can perform their work. He is the owner on the process but, if we go by the book, he has no authority over the team members. Some companies solved that by using line managers in combination with Scrum Masters, some company solved that by using Project Managers as Scrum Masters with additional responsibilities over team members (in which case the Scrum Master role actually became a Project Manager role). Whatever works is fine. In any case, whoever owns the process needs to know how to do it. Whoever owns the responsibility over the team members needs to know how to do it. For this and for much more, the project management core knowledge is a must.
The structure of PMBok is based (on the latest edition because they are also continuously evolving and adding new stuff with every new edition) on 47 processes. These are grouped into 5 groups and 10 knowledge areas. In order to do the things by PMI"s way, we need a certain structure which fits this table. Here is the debate: does knowing this structured way of doing things help me at all in my Agile day to day work (aka in my case on the Scrum process) or is it a total waste? Of course it does.
Let"s start first with the five Process Groups: Initiating, Planning, Executing, "Monitoring and Controlling" and Closing. The normal life of a project. Every project needs to be initiated. We cannot start a project in the middle. There has to be an initial phase. Even when we get to a nasty situation of continuing the work done by somebody else (nasty mostly through our ego because we are more accomplished as persons when we start a project from nothing and we get it to the finish line; otherwise it"s a perfect opportunity to blame "the old guys" for every mistake and bug that appears from the moment we took over until the end of project life). For example one of the things that we need to do, no matter what framework is used to do the work, is to identify the stakeholders in the initiation phase. So far, so good. Let"s jump to planning. In order to follow PMBok guidelines, you plan how you will do everything from the beginning and you can update as you go. As an Agile practitioner you plan all day long but in smaller pieces. If you go by Scrum rules, you plan a release (which ideally you adjust as you go), you plan an iteration, you plan your daily work. Executing, monitoring and controlling are about doing the work. What does the project manager or scrum master do in this case? The same thing: he manages the work, manages the communications, manages the stakeholders, manages the quality assurances, controls risks, controls everything (and sometimes controls more than anything, which is quite scary isn"t it?). And all of this needs and end, so, there has to be a Closing phase, no matter what.
Besides the Process Groups, PMBok organizes the information into 10 Knowledge Areas. Let"s go through some of them to see how we wrap the information over the Scrum rules. The big three group (time, scope, cost) remains the core of what we are doing. If in the structured PMI way we estimate from the beginning the time, scope and cost, when going into the Scrum way we do the same and we are doing it more often and in smaller pieces. When we plan a new iteration we need to take the same input into consideration: scope (which comes from a prioritized backlog), we need to adjust it based on a velocity which depends on the team (which translates together with other possible inputs in cost). And we need to do it in a certain period of time, which represents the sprint length. Very similar to breaking down the work in order to have the WBS, we are breaking down the stories into smaller pieces. If we think at one project which goes over the PMI rules as a reference (and waterfall projects are wrapped perfectly on this structure), we can see each iteration as a "mini-me" of that reference: well organized, well planned, well defined, with a fix length in time.
Another important knowledge area is risk management. Either way is an ongoing process. We evaluate the risks as we know. And in order to be efficient we need to know the core of this. There are several tools which we can use to analyze the risks and once we have the risk we need to weight them. We need to know which the most important ones are, which have the biggest impact and which ones need an action item. We can make a plan to avoid the risk, we can make a plan to mitigate the risk, we can make a plan to transfer the risk. Knowing our options can help us be more efficient and doesn"t depend on the framework we are working with (Scrum, Kanban). And suddenly the structured information doesn"t seem so far away from Agile world as we thought in the beginning.
As Scrum Masters we will own the process and we will work to remove impediments from the team. There are many times when third party services are required. It can be something easy like buying a third party UI controls set which will save us a lot of work, and it can go deeper like integrating a provider for online support with our brand new product. What we need to know is how to manage procurement. We will need to know how to set the rules for vendors selection and how to make a contract with them.
If by the book the Scrum Master doesn"t have the ownership over the team, that doesn"t mean that in the teams there will not be conflicts (ideally there shouldn"t be, but life would be so boring if everybody liked everybody and they all agreed with each other all day long). And it doesn"t mean that there will not be demotivated people. Human resource management knowledge gives us insights on how to manage this kind of situations. Everybody heard about Maslow"s Hierarchy of Needs, but there are many more theories. A minimum knowledge about this area gives us again the possibility to adapt to the context, the possibility to choose the right solution.
We don"t need to go deeper into each knowledge area, but if we do, we will see that the core knowledge which is needed to do things by PMI"s way, applies also into the Agile frameworks. Our evolution as managers should not stop at the level of one framework. The more we know, the better we can act. The more options we have, the better we can choose the right way. We can adapt, mix, and use what we know in order to obtain maximum efficiency. Core knowledge can come structured in many ways and methodologies (like PMI, PRINCE2 etc.). Agile frameworks shouldn"t push us away from the structured information. More than that, agile frameworks give us the power to juggle with it in the way we want, to be the rebels which are not following a standard and do a risk analysis meeting in the middle of the project because we think that is the right thing to do at that point. It"s up to us how we put all these pieces together, how we play with them. More pieces mean more combinations. More combinations mean more chances to succeed (and sometimes more chances to fail). But we will never know if we do not continue to evolve and learn more and more.
by Sorin Pânca
by Radu Murzea
