With this issue of Cutter Benchmark Review we continue our investigation into the management of the IT shop and of the many issues surrounding it. Earlier this year we investigated green IT (Vol. 8, No 5), enabling the agile enterprise (Vol. 8, No. 4), and developing solid business cases (Vol. 8, No. 2). Here we take our first in-depth look at the state of project management. This issue of CBR is also complementary to another piece we did recently that focused on agile programming philosophy and methodologies (Vol. 7, No. 7).
As I wrote in that issue, I have a pretty clear-cut stance when it comes to development success. In that issue, I recounted an experience I had serving on the steering committee on IT at Cornell during the university's enterprise resource planning (ERP) customization and installation project. Client representatives, who had been briefed multiple times about the status of the project, balked at the imminent introduction of a new course-numbering scheme. I went on record then with a clear position on project failure:
We could debate about where the responsibility lay in my Cornell example. The clients and other stakeholders in this case were as guilty as the project team and developers because they were sleepwalking through earlier meetings. Well, let's short-circuit this discussion right away. Just like professors and researchers bear the responsibility of readers' engagement and understanding when they write their articles, so do you as development professionals bear the responsibility if clients are not satisfied. Maybe you did not engage them or perhaps did not prepare them well enough to contribute to the effort. Either way, those who make a living designing and developing systems should be responsible for ensuring that the development process works. A harsh stance perhaps, but as one of our contributors puts it: "It's the customer, stupid!"
Agile software development has emerged as a viable option for enhancing speed of delivery and customer satisfaction in systems development projects.1
Project managers, like waiters in a restaurant, are of course the linchpin in this process -- and the ones that can make or break the effort. A great waiter can make your dining experience feel exceptional even when there are problems in the kitchen. Conversely, the same waiter can keep the kitchen working smoothly even with the most demanding and finicky of diners. By the same token, a bad waiter will create a disaster in normal conditions!
Like the wait staff, project managers sit between development needs and client needs and must be the glue that keeps the project together while being the lubricant that keeps the operation running smoothly -- not an easy task. Add to this mix the constantly evolving set of development methodologies and tools and the suggestion that "those who make a living designing and developing systems should be responsible for ensuring that the development process works" and you have a harsh stance indeed.
Having set the expectation, we at CBR thought it would only be fair to do our part. For this reason, we conceptualized an issue on project management. More specifically, as a charge to our authors, this time we posed the question of benchmarking project management in the age of agile programming. How should project management evolve, or not evolve, to keep pace with the changing systems design approaches?
Taking on the challenge from the academic side is Kathryn Brohman, Assistant Professor of Management Information Systems at the Queen's School of Business, Queen's University, Kingston, Ontario, Canada. I have known and collaborated with Kathryn for more than five years now as we share an interest in customer service systems and IT-enabled service. But Kathryn is also a recognized expert in systems design and development and a project management coach.
Our practitioner view is offered by Carl Pritchard, Principal of Pritchard Management Associates, a project management training and consulting firm based in the greater Washington, DC, area, and a Senior Consultant with Cutter's Enterprise Risk Management & Governance practice. Carl is a prolific author and speaker on the subject of project management, as well as one of the authors of the forthcoming Guide to the Project Management Body of Knowledge, Fourth Edition (PMBOK Guide).
Kathryn begins her contribution with an overview of project management tenets in the age of agile programming, identifying both commonalities and points of departure from more traditional approaches. With this frame in place, she reviews and comments on the survey results. Her focus, which I think you will find very interesting, is on the effectiveness of agile projects and the perceptions of traditional and agile project management practices.
Carl takes a narrower perspective focusing mostly on analyzing influencers and decision making with regard to project management approaches, a decision that is becoming increasingly complex and important. This is an interesting discussion with a number of surprising results.
As you will see, this installment of CBR takes a bold stance, thanks in large part to our authors who have opinions and are not afraid to voice them. I, for one, love this style of writing, and I make it a point to let contributors know at the outset that CBR does not shy away from conflict and differences of opinions. It is in this tension that I believe great insight can emerge. I hope we succeeded and that you will find tangible and useful insight in the pages of this issue.
ENDNOTE
1 Piccoli, Gabriele (ed.). "Making Agility Stick: What's Working, What's Not. " Cutter Benchmark Review, Vol. 7, No. 7, 2007.
