The New PMBOK® 4th Edition & Software Applications Development

Last weekend I attended a presentation on the differences between the new PMBOK® 4^th Edition and the previous 3^rd Edition. This presentation was given by Kim Caruthers at Nova Southeastern University in association with the South Florida Chapter of PMI. I had already purchased the new edition in the hopes of keeping current with best practices (an old dog needs constant training to do new tricks). I had read 2 sections, Collect Requirements & Identify Stakeholders, both in conjunction with previous posts to this blog, or for assignments to measure the effectiveness of our current processes in doing these specific things. My last post raved about the Requirements Section, & I was pleased to see that some of the techniques I had discussed in an earlier post on Software Development Stakeholders were now firmly part of the new PMBOK®.

The presentation lasted 4 hours & it was way too short. It could easily have been 8 hours. It became apparent that in 4 hours, we would not be learning the new edition; we would mostly be discussing the format changes. There were a few new acronyms & a ton of retired acronyms. BTW, the processes now all follow the verb noun format. There were new items in the glossary, no new concepts, just new glossary items. I’m going to borrow terms & phrases from both the PMBOK® & from Kim’s 283 page PMBOK® Guide Differences presentation. As an aside, the class had twice the anticipated audience, about half were there because they now had to take the PM Certification test with the new edition, another 40% were there for PDUs, and the rest of us were there for personal education only. The presentation was geared for test takers (even I had to take a pre & post test, results not admissible in a court of law). Good luck to the PM Certificate test takers, I’m sure you’ll do fine.

There is a greatly increased emphasis on interpersonal skills & the realization that PM’s accomplish work through the team & stakeholders. There’s an entire appendix ( Appendix G) covering these topics that speak directly to the qualities a good PM needs to be successful. I follow several blogs dedicated to Project Management or Software Development & this has become a bigger & bigger part of the landscape. I especially recommend Project Shrink to those interested in the people part of Software Project Management. The explicit inclusion of interpersonal skills in the new edition is extremely gratifying. Agile Software Development demands more interpersonal skills & we had better all become more agile & more people oriented.

Collect Requirements is a new process to the book, certainly not a new process to Software Developers (or any other project management field). Failures in this area are one of the major contributors to failed, overdue &/or over budget Software Development projects. Develop Preliminary Project Scope Statement has been removed; evidently either the Project Charter or the results of the Collect Requirements process will suffice. In the course of this the Scope Planning Process has been removed for the same reason. BTW, the book now suggests that the PM have an active role in developing the Project Charter. This is something we have all been doing, but it has now been acknowledged. There’s a new process called Report Performance. We’ve always done that as part of Monitor & Control, but now it’s its own process under Communications. Collect Requirements also references well known facilitated workshop techniques (JAD, QFD, VOC & HOQ). Mind mapping is also explicitly discussed. There are many Mind Mapping software offerings available, some free, some at a varying costs. Some can interface with other PM software ( MS Project for instance). I use Free Mind.

There is an expanded discussion of the relationship between Projects, Programs & Portfolios which bears reading both for organizations which have PMOs & PPMOs & for those who don’t. Those of us who don’t have either offices end up having to do both anyway in order to comply with our ethical responsibilities, & we have to do it without the resources & access to do it properly.

The Business case has become recognized as in input to the development of the Charter. I have always felt that the Business Case was extremely important & that lack of it leads resources being applied to the wrong projects. I’ve been recently soliciting help & feedback on Business Value & have gotten some extremely helpful responses, but that’s another discussion. It all comes back to the keystone of Agile Development, delivering value. This concept now has been translated to Project Management on many levels.

There has been an acknowledgement of the place that both processes & documents (artifacts) have. Processes usually produce Documents, which serve as Inputs to other processes. Some of these documents have been identified & discussed in detail. The Stakeholder Register is one of these. PERT & other risk documents & techniques are also discussed. One of these days, I’ll post an article on PERT in risk management which will change the common view of PERT as a scheduling or cost tool.

All in all, the new PMBOK® is an advance in techniques & concept. It’s more reflective of the Agile Development world & of the importance of people skills. It’s worth the time & effort to get familiar with it.

Gathering Requirements

I was going to post an article on gathering requirements. I went through the PMBOK 3rd Edition & followed up on the 40 or so references to requirements. I solicited requirements gathering tips from various groups. Then I read Chapter 5, section 1 of the new PMBOK 4th Edition. There's not much left to blog about as far as gathering requirements go. This is one of the best written, most comprehensive & informative PMBOK entries I have ever read.
Last month I wrote an article about Software Development Stakeholders. I even invented a spreadsheet of stakeholders, their interests & influences. Lo & behold, the new PMBOK shows a Stakeholder Register as in input to the Gathering Requirements process. This register is defined in section 10.1 & has most of the attributes present in my stakeholder list. Indeed, almost evey topic I had come up with was covered in the Gathering Requirements section.
I did get some userful responses to my queries. Vincent Chiew (ITIL FFCP ISP CISSP CSSLP PMP PEng) , reminded me of that public sector projects may have thousands of stakeholders & that made surveys & public meetings one of the few ways to obtain requirements from large groups of stakeholders. Epifanio (Jun) Bucao (PMP)(BAS), whis both a PM & a Business Analyst, recommended Rapid Requirements Discovery as a method for gathering requirements, which brouoght up the whole subject of Business Analysts. In my own personal case, we don't have Business Analysts per se, but their function is performed by our own Software Consultants, who have considerable industry experience & contact with our customers.
David Gilbert, D.Sc. PMP, introduced me to the BABOK, the Business Analyst's Book of Knowledge. Now I have another book to read. It's clear to me that Business Analysts have a place in defining the real business needs, and that they have an advantage in doing the root cause analysis of the business case. I'd love to have them analyse prosective projects before they even get to me, so that I don't have to spend an inordinate amount of time finding the real problem to be solved.
Kit Johnson, PMP, reminded me to focus on the need & not on the project. The Business Objective & Goals are much more important than the design. As in everything to do with PM, it's aways important to remember that people are what make successes.
I never did get a list of standard questions to ask in an interview, which was one of the things I had asked for. I guess there are no shortcuts, every project must be approached as a single unique problem, so there's no magic list of standard questions, even for applications development. I always ask if the project is replacing an existing app or process, & if so, why does the user want to change what they already have. A series of 'Why?' questions usually leads to the root cause. If there is an existing system, I try & watch it in use & talk to both the user & the customer about the system.
In closing, the new PMBOK's requirements section is magnificent. I'm so impressed by the document, that I've signed up for a course on the differences between this edition & the last. This course is given in conjunction with the South Florida PMI Chapter. I'll report on that when it's done.

Software Development Stakeholders

The PMBOK® defines stakeholders as any persons or organizations impacted by the project. They all have interests, involvement & influence on the project’s success. Most stakeholders are common to all types of projects, but this list is geared towards Software Development, & is being posted in an attempt to provide a resource to Project Managers of Software Development projects. If you have had projects with stakeholders not mentioned here, please comment on it & I’ll modify the article to include them & give credit to any contributors.

Let’s look first at the most obvious stakeholder, the customer. By customer I mean the entity that has commissioned the project & will be paying for it. Their interest is concerned with the success of the project in meeting their goals for functionality, cost & schedule. They should receive status reports & delivery of the product or service based on their defined needs as stated in the Project Charter, Statement of Work, Contract, RFP, or Specification. As project managers we owe them the product or service, up to date status reports & delivery of value as soon as possible. I my experience, prototypes & continual feedback from the customer is the best way to ensure success, in so far as they share in the ownership of the development of their product or service. The Customer may be represented by a CEO, CIO, CFO, President, Vice-President or any other upper or middle management representative. What is common to any customer is that they want or expect a successful project. They are at least as interested as you are in obtaining it. In order to satisfy the customer, you will possibly need to satisfy other groups of people, users and operators in particular, & the consumer of the final product or service.

Vendors represent another class of stakeholders. In the case of external customers, you are a vendor to them. Treat vendors professionally, just as you would like to be treated, & you can’t go far wrong. A fellow Project Manager, Chris Alberts, reminded me of this in his response to my request for contributions to this list. He wrote “third party software, hardware, interfaces, surround code vendors...any third party services vendors also....I'd also deeply understand your environmental factors when looking at stakeholders”. PMP Jeffrey Spardy, another contributor, wrote “Along the same lines of what Chris added, vendors of competing solutions and vendors of complimentary solutions”. Competition may certainly be interested or impacted by the success or failure of a project, & I’d certainly look at them for ideas & risks & opportunities. Complimentary solutions, services, applications & products certainly belong in the list. When I did a project for the World Trade Center, even though it was a Software Application Project, it included Sun Microsystems, AutoCAD, interaction with MVS & an external database. Hardware maintenance was provided by a local NY service company. Most vendors’ interests & commitments are directly related to their potential income, either from licensing, support, rental, publicity or purchases. Their commitment to the project’s success is directly proportional to their income.

As Chris also commented, your internal organization will contain many stakeholders, regardless of whether this project is internal or external. These may include functional managers, PMO’s, sponsors, CEOs, CIOs, CFOs, Presidents, vice-presidents, division mangers & other officers. They also include your project team. Of particular interest might also be the environmental & organizational structure of your customer, since this will give clues to how the product or service will be used by or impact them.

Another class of stakeholders might be represented by Government representatives, environmental interests, Professional organizations or societies, or other special interest groups.

With all this in mind, here’s an attempt at a list of possible stakeholders. In the table, high influence means that the stakeholders’ opinions will drive the development of the project, medium influence means that the stakeholders opinions must be considered in the development, & low influence means that the stakeholders opinions may be accepted or rejected based on their own merits. For Impact, high means that the stakeholders can stop the project or reject the product, & medium means that they some effect on schedule, cost or scope.

This document is not static, let me know of omissions or recommended changes, & we’ll work to incorporate them into a revised list.

Click on the table image on the right to see the table.