The Project Management Institute (PMI) has recently enjoyed an extraordinary increase in credibility, becoming the standard bearer for project managers worldwide. In the last decade, PMI has grown from an obscure specialist organization with around 8,000 members to its current membership of over 91,000.
The ranks of Certified Project Management Professionals, a certification conferred by PMI, have expanded, from a couple of hundred in the 1980s to more than 45,000 today. And PMI’s foundation text on project methodologies and practices, the Project Management Body of Knowledge (PMBOK), has more than 890,000 copies in circulation.
So how do these methodologies relate to IT? Can IT consultants simply adopt the PMI standards right out of the PMBOK, or will we need to think of IT-specific issues and modifications as we develop IT project practices? Here’s how IT consultants can explore and apply the methodologies in the PMBOK to our work.
First in a series
This is the first of several articles that explore the application of the PMBOK to IT consulting. The next installment will examine common pitfalls in project management.
Project management context
As elementary as it may seem, a review of PMI’s definition of a project is instructive. “A project,” according to PMI, “is a temporary endeavor undertaken to create a unique product or service.” While that may seem obvious, many IT pros find that clients often try to turn a temporary engagement into a lifelong commitment. They sometimes attempt to turn project work into outsourcing, dragging us from the creation of a solution into its operation and maintenance. Outsourcing is not a bad thing, but it’s a completely different business from project work.
We IT consultants need to be sure that our clients and sponsors have a clear understanding of what a project is; good consultants continually focus clients on the temporary nature, and the clear goals and objectives, of each project.
If we’re going to take on ongoing operational responsibilities, we do it under a separate agreement, to maintain a clear boundary between project responsibilities and operational duties. Failing to do so is one of the main causes of “the project that never ends,” because clients automatically assume that, as the implementers of an IT solution, we are also responsible for running and maintaining it. Clarity about the endpoint of a project is one of the foundations of good IT project management.
The perpetual client
Every practicing consultant has met clients who believe that, because we spent a billable hour helping them install a spreadsheet or accounting package, we also have signed up to support them for life. In my work advising IT consulting firms, I consistently run into consultants who can’t extricate themselves from engagements because they’ve neglected to create a clearly defined endpoint.
A student in my IT project management class, a project manager at a major government contractor, told me the story of a client who resisted training during the implementation cycle, always excusing himself with some other meeting or commitment that precluded him from attending. Once the scheduled training sessions were over and my student tried to close out the project and move to the next one, the client suddenly became frantic, calling her repeatedly, day after day, for assistance with simple tasks like entering data and running reports. My advice was simple: Refer the client back to the scope of work and project documents, which should have clearly defined the endpoint, the range of services, and the success criteria for the project.
Of course, this is difficult if you haven’t done the proper detailed scope definition up front. Project management discipline is a complete cycle, and omissions at the front end, including an incomplete understanding on the client’s part of the difference between project work and operations, create misunderstandings at project closeout time. This problem is hard to fix on the back end and often results in dependent clients and poor customer satisfaction.
Good consultants gauge their clients’ understanding of project management concepts and include basic education as a part of the engagement for clients that clearly don’t understand the difference between delivering a project and supporting a production system. Consulting is as much about educating as it is about implementing, and educating clients about project concepts is often as important to project success as giving them technical training.
Technology and management
PMI’s definition of project management is another elementary concept that merits closer examination. PMI defines project management as “the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations.” PMI differentiates needs from expectations for an important reason, one that is especially pertinent to IT professionals.
When IT technicians talk to clients, users, or stakeholders, we often focus only on the technical specifications. As the PMI definition emphasizes, however, technical specs are only a small part of the solution. Apart from the technical functionality that clients need, they also have expectations for look, feel, performance, usability, and quality that are often much harder for them to articulate.
For example, when you do design work, clients have imagined or visualized the results of your design and often have a picture in mind of what their Web site, screens, reports, or pages will look like, from the font style to the color. These mental images are separate and distinct from the technical requirements. Good IT consultants understand that needs refer to the technical elements, expectations refer to the perceptual elements, and both are equally important to project success.
Another important concept that PMI emphasizes is this: Project management is management. Most CEOs, CFOs, and departmental managers have had training in standard management practices such as:
- Strategic planning
- Delegation and supervision
- Business operations (such as research and development, production, and distribution)
However, it’s not unusual to find IT pros who’ve come up through the technical ranks and have had limited exposure to these general management principles. As PMI states in the PMBOK Guide, “General management skills provide much of the foundation for project management skills.” IT pros who want to be successful project managers need to acknowledge that successful project work is about more than technical proficiency.
I’ve observed many managers of IT firms who disrespect project management and believe that strong technical abilities can solve any IT problem. Sometimes clients do the same. Every experienced project manager and consultant, however, can tell war stories about projects that were implemented successfully on the technical end but failed miserably due to lack of management skills such as leadership, communication, negotiation, and problem solving.
When leading organizations through difficult changes, communicating about project expectations and issues, and negotiating complex and often competing stakeholder agendas, project managers who are pure technicians, without a grounding in basic management practices, are at a disadvantage. I advise my clients, and all IT consultants, to view these general management skills as a necessary component of their continuing education. Look for opportunities, from books, courses, and mentorship, to develop these skills along with your technical prowess.
Do you use the PMBOK?
Has the PMBOK served as a framework for your IT projects? Post your comments.
Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile practices and migrate successfully.