Your organization understands project management. You have schedules and budgets, you get frequent status reports, and every project manager is an ace at using one or another project scheduling software package. But projects still come in late and over budget, people are working long hours most of the time, and you spend entirely too much time fighting fires. Why? What does it take to get things to run smoothly? What are you missing? My program in Advanced Project Management is intended for organizations that have a project orientation, and have solid experience applying project management skills, but somehow find that the results they're getting are disappointing. They're puzzled about what might be the cause.Most of the time, there is no one cause — the missing pieces relate to understanding the environmental factors that must be met for projects to succeed. The problems are often in the fabric of the organization, in how they understand the nature of project work, rather than in application of specific project management techniques.
Most of the difficulties organizations face when managing projects relate to the fundamentally untestable nature of much of the work they do. For example, when you're developing requirements for a software project, the "work product" is a set of requirements. Unlike software, requirements cannot be compiled, executed, and debugged — to "test" them, we have to think about them.
For an organization that relies on testing to ensure quality, the requirements activity can be very challenging, because requirements, as such, are fundamentally untestable. It is only when we finally build systems based on those requirements that we can really test the requirements for consistency, accuracy, and completeness. Even then, the test is indirect — what we actually test is the system, not its requirements.
When the work product is fundamentally untestable, ambiguity and uncertainty tend to accumulate over the life of the project. As work progresses, the team becomes more and more dependent on the accuracy of work already performed, but because that work is untestable, the team can never be certain that that work is correct. At some point, there comes a day of reckoning, and too often, the team learns that something it has been assuming was OK actually isn't. This is the cycle that leads to delay, rework, and endless firefighting. The consequences of this dynamic appear in a variety of forms.
We explore these issues, define their relationship to project success, show how conventional project management practice fails to address them, and give participants practice with the interventions needed to mitigate their effects.
Program structure and content
We explore the consequences of untestability. We learn about the limitations of conventional project management practices relative to this environment, and introduce new tools that fill the gaps in these conventional practices. Through a series of experiences and simulations, we develop sophisticated project management tools, and apply them to simulated project work. This program is available as a workshop or clinic. Topics include:
- Roles, responsibilities, and conflicts of interest in the project environment
- The hierarchy of needs for projects
- Designing orthogonal work breakdown structures
- Reviewing and inspecting inherently untestable work products
- Designing metrics for untestable work products
- Scheduling inherently unpredictable tasks
- Anticipating speed bumps
- What to do when you're stuck
- Circulating information proactively
We usually think of project management skills as rather technical — free of emotional content. We hold this belief even though we know that our most difficult situations can be highly charged. Despite our most sincere beliefs, taking a project organization to the next level of performance does require learning to apply knowledge management skills even in situations of high emotional content. That's why this program uses a learning model that differs from the one often used for technical content.
Our learning model is partly experiential, which makes the material accessible even during moments of stress. Using a mix of presentation, simulation, group discussion, and metaphorical team problems, we make available to participants the resources they need to make new, more constructive choices even in tense situations.
Leaders and managers and technical project team members. Participants should have experienced at least six months as a member of a technical project team.
Available formats range from a half-day to two days. The longer formats allow for more coverage or more material, more experiential content and deeper understanding of issues specific to audience experience.
- "Rick is a dynamic presenter who thinks on his feet to keep the material relevant to the
— Tina L. Lawson, Technical Project Manager, BankOne (now J.P. Morgan Chase)
- "Rick truly has his finger on the pulse of teams and their communication."
— Mark Middleton, Team Lead, SERS