Project Management has changed from Outputs to Outcomes
Everyone can cook, but not everyone is a cook. Everyone can sing, but not everyone is a singer. Our profession is no different: everyone can track teamwork, but this does not make them project managers. If we need to know if a cook is a good professional, we do not need evidence to ensure that certain procedures are followed. We check the value result: we taste his or her food. The 8 project management performance domains in PMBOK7 makes everybody can tell if the project is being well managed.
Lessons Learned in Projects
Registering lessons learned often requires the project team to write some formal documentation. Discussions about lessons learned typically occur during the project closure meeting. Team members don’t remember the details, are reluctant to write about mistakes, and are already thinking about the next project. These discussions are valuable for personal growth and building professional relationships but, after the meeting, there is no reusable document with explicit knowledge. In PMPeople, the project management team can register lessons learned as they occur, reuse lessons from other projects, and prepare their own for future reuse.
Process-Less Project Management
Managers don’t buy project management. They approve projects but don’t assign anyone to oversee the big picture, anticipate problems, make forecasts, be accountable, and ultimately, take responsibility for achieving success. They see that the project team self-manages through meetings, which they sometimes attend for information and other times to address issues on the fly. A project professional would know how to do it better, but since we have a reputation as bureaucrats (documents, processes, workflows, and more meetings), they prefer crises, that is, reacting by improvising when problems arise and it’s too late.
Performance Appraisal for Project Managers based on PMBOK7
Everyone can cook, but not everyone is a cook. Our profession is no different: everyone can organize tasks, but not everyone is a project manager. Normal people –non PMP®– should be able to tell if a project manager is a good or a bad professional. PMI® published a practice standard named “Project Manager Competency Development Framework” (PMCDF), based on the processes of PMBOK5. We can anticipate the next edition of the PMCDF will be aligned to PMBOK7, implying all stakeholders will be able to check good or bad project performance on 8 performance domains.
Practicing the PMBOK® Guide 7th Edition with PMPeople
PMPeople can be seen as a technology framework for practitioners who want to follow the new edition of the PMBOK: As a project manager, I can follow the 12 principles just updating the project data in PMPeople. As a stakeholder, I can check the project management outcomes on the 8 performance domains just getting the evidence of good or bad performance directly on PMPeople.
Controlling Agile Projects
In agile projects, there is a disturbing complacency about failure. We are used to statements like «I’ve seen no software project delivered on time, on budget». Do you really think this a problem without a solution? If we let the team do their tasks but nobody is accountable for the project, why is it a surprise when the project is behind schedule and over budget? Agile projects must be controlled as well.
Agile Case Study (5/5): Closing the First Release
This is the fifth and last post on the chapter 23 of the book Agile Estimating and Planning, by Mike Cohn. In the previous post the team was about to start the first 2 week iteration, planned with 4 stories and 18 points. They also forecasted a…
Agile Case Study (4/5): Release Planning
Fourth post on the chapter 23 of the book Agile Estimating and Planning, by Mike Cohn. In the previous post the Havannah team met with on this agenda: First sprint planning. Market research outcomes review. Initial estimate for the release plan and the project schedule. First point…
Agile Case Study (3/5): Planning the First Sprint
Third post on the chapter 23 of the book Agile Estimating and Planning, by Mike Cohn. In the previous post the Havannah team had written 32 user stories, totaling 146 story points. In this post, team members are working on another project, while analyst Delanie start a…
Agile Case Study (2/5): User Stories
Let’s continue reading chapter 23 of the book Agile Estimating and Planning, by Mike Cohn. In this second post you will realize about the convenience of writing down physical cards and how to conduct a brainstorming session to make team members infer requirements, a.k.a. user stories. A piece…