PMI continues with its annual publishing of extensions to the Project Management Body of Knowledge (PMBOK). This year they finally published the long awaited Software Extension to the PMBOK Guide Fifth Edition. The extension includes widely accepted practices in managing software projects.
The structure of the software extension is the same as the structure of the PMBOK guide. Each chapter includes extensions which are applicable to software projects. Some chapters have no extensions or very few of them, for example change management, which in software projects doesn’t differ from the widely accepted change management as described in the PMBOK.
We find more extensions in the areas of risk management, communicating with stakeholders and monitoring and controlling. We know that software development presents numerous risks and that these types of projects are often not successful. We should be spending much more time and focus on risk management and relevant communication when managing IT projects.
PMI does not take sides for either traditional or agile project...
Mitch Lacey's book »The Scrum Field Guide: Practical Advice for Your First Year« is an extremely useful book that helps new Scrum practitioners take the first step from learning about Scrum to actually doing it. The book does not explain the basics of Scrum and its artifacts because it assumes that the reader is well informed already and wants to go from theory to practice. Each of the 30 chapters in this book jumps right in and gives practical advice that may be used in a real Scrum project.
Most of the chapters are structured similarly. At the beginning of the chapter there is a real life story as an example. Some of the topics that are covered in the chapters include: getting people on board, optimizing team performance, determining team velocity, implementing team roles, establishing core hours, presenting the case for a full time scrum master, establishing good engineering practices, understanding when we are done, release planning, decomposing user stories,...
All of us who manage IT projects know that risk management is very important. At least that is what they teach us. However, do we really manage risk in the real world, do we pay it enough attention and last but not least, do we even understand the meaning of project risk management? -- MonitorPro 02/14, p. 28-29...
Once again I was invited to participate in PMI's publication PM Network, this time in their June 2013 issue. I contributed tips about how to be more productive on projects.
The article lists ten miscellaneous tips for project managers. One of them was mine, about resolving minor issues by clearing the air via telephone call rather than entering a lengthy email correspondence:
“Whenever I detect an undertone such as sarcasm or anger in an email, I never respond by email. I usually telephone the sender and ask him or her to clarify, which allows me to get a clearer understanding of his or her motives. We can resolve minor issues in passing, not having to explain them in lengthy emails.”
In my project management experience, I find it much more efficient to pick up the telephone and call someone when there is an issue to be resolved, a matter to be settled or something ambiguous to be clarified rather than firing off an email. By...
PMI published the newest, fifth edition of the Project Mangement Body of Knowledge or PMBOK, the worldwide recognized project management manual.
As with each new edition of the PMBOK there are numerous minor updates. This time, however, there is a major update and that is the addition of a completely new chapter. It deals with a new knowledge area that should be familiar to all project managers: stakeholder management.
I have to wonder what was the reason for introducing a completely new knowledge area that a project manager should master? Was this knowledge area not required previously? Are there any new circumstances that caused the need for a new knowledge area? Or was this knowledge there all the time, it just wasn't grouped together in a chapter but rather split in processes here and there? A detailed reading of the new chapter reveals that it is indeed the latter. Project Stakeholder Management was there in previous versions of the PMBOK, covered in several...
After more than 20 years in corporate IT consulting environments, I volunteered my project management services to a non-governmental organization (NGO) in Cambodia. Here are some of my experiences of the challenges facing project managers in NGOs and in developing countries in general.
NGOs are non-profit organizations that typically function in the areas of social development and improving the quality of life of underprivileged individuals. They are most often funded by international aid and donors.
Initiatives from NGOs are usually performed as projects. The aims of such projects may be to
alleviate poverty
improve living conditions
ensure human rights
protect the environment
help victims of natural and man-made catastrophes
further develop the health and education systems
Project success is measured in terms of socioeconomic progress and the levels of desired outcomes that resulted from the project. In turn, this translates into effectiveness of the donor funds. These types of results are not always tangible in nature and may not be straightforward to measure.
Project...
In their book Green Project Management authors Richard Maltzman and David Shirley tell us that project managers are inherently green because they constantly strive to decrease costs, increase business value and protect scarce resources. This all contributes to being green. Companies are increasingly more aware of the need to become green and therefore it makes sense that project management becomes green as well.
The authors introduce a new term that denotes the level at which a project is green. The term is greenality and was chosen because it sounds similar to quality. They argue that greenality can be managed the same way as quality, for example, we could introduce a greenality management plan. We could measure greenality both in the project sense and in the end product sense. They even suggested that greenality might be added to the Project Management Body of Knowledge (PMBOK) as a new knowledge area.
They further explain the analogy between greenality and quality by introducing the cost of...
When we talk about agile projects and the most popular agile approaches such as Scrum, XP, Lean or Kanban, there is never any mention of specific team member roles that correspond to waterfall projects. For example, where are the specialists, such as system architects, database designers, or business analysts? Are they no longer relevant in agile? Or are the tasks that would have been performed by people in these roles fulfilled in some other way?
Let’s focus on the role of the business analyst, a role that is vitally important in waterfall projects and as we shall see it is implicitly addressed in agile projects as well.
In general, the business analyst can help agile teams by representing the customer, especially when the business domain is complex and the team is not very familiar with it. He or she can elaborate the requirements and clarify their purpose in the business environment.
What the BABOK says about agile
For more information about the business analyst...
Project Management Institute (PMI) published the results of a major research in 2009 which confirmed that project management adds value. The result was expected because all of us who are professional project managers believe in its merits. This research was the first of its kind to scientifically prove our beliefs. -- GEA Forum Issue 13, september 2012...
Contrary to traditional project management where risk management is an integral and crucial part of the project management process, there is no explicit mention of risk management in popular agile methodologies. This makes us wonder whether we manage risk on agile projects at all. It should make sense that since agile project management differs from traditional project management, agile risk management should differ from traditional risk management.
There is an understanding that agile does not explicitly define risk management simply because agile manages risk implicitly. How does that make sense? There is a good explanation in the book “Becoming Agile: …in an imperfect world” by Greg Smith and Ahmed Sidky where the authors state that “a secondary definition of agile could be continuous risk management”. In fact, agile processes are intended to stay on top of risk management by making the team alert and responsive to new information and changes as the project progresses.
Implicit agile risk management
There are several aspects of...
