Advanced Technology Project Management
Essential characteristics of a project
Definition: Project — A temporary endeavor undertaken to create a unique product or service. [PMI]
Preconditions (required before starting a project):
- Definition of the deliverable unique product or service
- Willingness & ability to dedicate resources to project
- Defined start and end dates
Critical success factors (must be in place for project success):
- Project runs from definition to delivery — "from the client to the client"
- Strong PM in place
- PM role has total responsibility and authority for the defined objective (including direct client interface)
- Project has exclusive control of its allocated resources
References
You'll note that there is not a single PMI book here. I think that we have over emphasized the tools of project management, at the expense of the core of it—project leadership.
Below are a few references that give PMs some perspective on leading and decision-making in our industry.
Strongly Recommended—Must Have
Object Solutions: Managing The Object-Oriented Project
By Booch, Grady
Addison-Wesley; 08/1995
Softcover; 323 pages
ISBN 0-805-30594-7
Booch gives an excellent set of pragmatics, background, and principles for managing projects. His focus is on OO projects, but the lessons of this book transfer to almost all software engineering projects. Readable, useful, and original.
Exploiting Chaos: Cashing in on the Realities of Software Development
By Olson, Dave
Van Nostrand Reinhold; 10/1992
Softcover; 239 pages; Out of print
ISBN 0-442-01112-1
Chaos is not randomness. Olson explains how complicated systems (like a software engineering project and its business environment) can be chaotic—knowable but not fully predictable. But, this isn't a theoretical treatise. Olson then explains how this understanding changes how we build our systems, manage our projects, and structure our business. This is a rare kind of book that'll change how you look at our work.
More Chaos
The ACM's Software Engineering Notes published a set of articles from a software engineering researcher who writes under the playful pen name of "L. B. S. Raccoon". These short articles discuss chaos in software engineering:
L. B. S. Raccoon. "The Chaos Model and the Chaos Life Cycle". Software Engineering Notes. Volume 20, Number 1, Pages 55 to 66, January 1995, ACM Press.
L. B. S. Raccoon. "The Complexity Gap". Software Engineering Notes. Volume 20, Number 3, Pages 37 to 44, July 1995, ACM Press.
L. B. S. Raccoon. "The Chaos Strategy". Software Engineering Notes. Volume 20, Number 5, Pages 40 to 47, December 1995, ACM Press.
Get copies from the ACM Digital Library.
How to Lead a Successful Project
Tom Peters has written a series of books about leadership/management, starting with the classic, In Search of Excellence. Of his books, here are two that are most concretely applicable to project management, but I highly recommend all of Peters' books:
Thriving On Chaos: A Handbook for a Management Revolution
By Peters, Tom
HarperCollins Publishers; 01/1989
Softcover
ISBN 0-06-097184-3
A cookbook for innovation, team leadership, client relations, team members, and systems/controls. Intended to be used as a guide—just flip to your topic of interest for quick advice and ideas. Tom Peters' irreverent style is intrinsic to every recommendation.
Liberation Management: Necessary Disorganization for the Nanosecond Nineties
By Peters, Tom
Fawcett Publishing; 02/1994
Softcover; 835 pages
ISBN 0-449-90888-7
Peters discusses speed to market, new organization structures—teams, networks, and projects—as well as knowledge management, innovation, and "fashion". This book is full of "real-world" stories and written in Peters' enthusiastic manner, which makes it fun to read. But, it's not "fluff"—Peters addresses some of the fundamental changes in today's business world.
J^T Thoughts
Violating the Role of Project Manager
In dysfunctional organizations, I often see are two problems in the area of project management: the role has been destroyed and many of the incumbents are not up to the task. It's often not clear which is the cause of the other, but both need to be addressed.
First, the role of Project manager is defined by the SEI as:
Project manager — The role with total business responsibility for an entire project; the individual who directs, controls, administers, and regulates a project.... The project manager is the individual ultimately responsible to the end user.
I use the analogy to a Naval Captain. (The ship is the project.) Within the realm of the ship, the captain is "god". He/she has authority over all persons on board and clearly directs all activities of the ship. The captain's experience, skill, and judgment add credibility to the de jure authority.
Similarly, the project manager's "total business responsibility" and exclusive control of the project's resources permit the PM to drive the project in a very focused manner to its outcome. To do this requires significant skill, knowledge, and experience in the business and technical domain of the project.
In dysfunctional organizations, the role of PM exists in name only. The authority and project-wide scope of the role has been completely eliminated. The remainder of the role seems to have become clerical: meeting coordination, schedule updating, status report fill-in-the-blanks, etc.
Fix: Consolidate the control of a project into a real "project dictator" role, with "buck stops here" decision making authority and full control of all project resources.
Second, the pool of incumbents is inadequate. Many of the "PM"s (in fact, many people with detailed delivery management titles) that I've met are nowhere near to having the "significant skill, knowledge, and experience in the business and technical domain" of the work they're managing. (This is not universally true, but prevalent.)
Project management is a senior role, not an entry-level role. The project manager must have done the type of work that the PM is managing. There is no other way to get the skill, knowledge, and experience needed to make correct judgments, ask the right questions, and identify the right risks.
In order to recruit and retain "qualified for command at sea" PMs, the role problems must be corrected, though, because talented PMs will not tolerate being a project clerk.
Fix: At the same time as the role is corrected, recruit PMs from successful technical staff that have good client relations skills.