Author: Eric Tse

Abstract

This white paper suggests project management methods and practices can move from a static, unidirectional framework, to a dynamics, multidirectional framework. We focus on how project role dynamics and process dynamics can benefit a modern complicated project environment. Although some of the dynamic practices are well known informally, the whole framework can be improved by introducing them to the formal project management methodology literature. Besides role and process Project Management dynamics, there can be other dynamics topics that are worthwhile to investigate and get introduced in future Project Management models.

Introduction

There have been traditional management theories and techniques for many years. In this paper, we are trying to review the newer management practice by introducing the concept of “dynamics” into existing the traditional Project Management model and methodology.

Many of the concepts are not new.

• Some of them are philosophical insight from the orient.
• Some of them have been utilized in software engineering or industrial engineering, but haven’t got formally introduced into project management methodology.
• And some of them people may have been doing it everyday in modern enterprise, but they haven’t formally been introduced to the formal PMI framework.

By integrating these elements into our daily management practice in project management or project execution, project members can achieve better project outcome and better career satisfaction.

Two Dynamics

We focus on two dynamics:

• Role dynamics
• Process dynamics.

Role Dynamics

Traditional US managers are more concerned with role clarity. They are concerned with who is responsible to do what. The task has to be clearly outlined before things can move forward. If you are in a role A and you do work of role B, you will get into trouble [1]. The following diagram from PMBOK may illustrate how role is defined in a normal PM HR process. [4]

informally. By frequently meeting each other, there can be informal and social gatherings. During those events people know what they need to do and things can be worked out without insisting on documenting clear role matrixes.

It may make things easier to communicate at the beginning if there are clear cut roles and stuff. On the other hand it may make people interpret this behaviour as a display of distrust and view it with suspicion [2]. This would more likely to happen if US people want to manage Eastern people.

Moreover the very nature of the project as a unique cluster of tasks can often call for a certain degree of role ambiguity not often prevalent among the rest of Americans. With a rigid role system, members tend to have less flexibility to change their roles if they need help to meet the changing needs. Team members may think it is other people’s responsibility to carry out that role, so even if the person is swamped, other people cannot give them a hand unless the whole team get a common consensuses through formal project management notification. [3]

On the other hand, especially in a large enterprise, team members with different roles may be afraid of helping the other team members, preventing overlapping roles, offending people by performing their role, or trying to take existing power from other people. These may be because of role overlap or conflicts can have influence on performance evaluation.

Also by exchanging roles, team members can expand their skills of individuals. This can provide project redundancy, and better career development satisfaction.

Process Dynamics

From the PMBOK, the project management knowledge areas and processes are relatively linear, unidirectional and static. [4]. Although the steps inside the processes are rich and complex, you can tell things are being done in one direction. The steps would not be iterative or going back and forth.

For example in the following planning process groups, you can see things are not iterative, and this implies there are not too many dynamics happening. Step A executes, then step B, then step C, and then Step E, after Step C and Step D is finish. [4]

Although PMBOK is complex enough conceptually for project managers to use to grasp, in real life, the lack of dynamic nature of the current PM model may not be sufficient if the development project is complicated. Sometimes you may go back to the planning phase after design phase, or processes may interleave each other. If a project manager doesn’t think out of the box, it may take more effort to achieve certain goals.

On the other hands, dynamics development methodology, such as the Rational Unified Process (RUP) may give us some more insights into how project management can be done in more complex environment. Although RUP is mostly used for software development, the dynamics concept can be borrowed by the project management knowledge area.

In RUP, they suggest things should be built iteratively.

“Given today’s sophisticated software systems, it is not possible to sequentially first define the entire problem, design the entire solution, build the software and then test the product at the end. An iterative approach is required that allows an increasing understanding of the problem through successive refinements, and to incrementally grow an effective solution over multiple iterations. The Rational Unified Process supports an iterative approach to development that addresses the highest risk items at every stage in the lifecycle, significantly reducing a project’s risk profile. This iterative approach helps you attack risk through demonstrable progress frequent, executable releases that enable continuous end user involvement and feedback. An iterative approach also makes it easier to accommodate tactical changes in requirements, features or schedule.” [5], [6], [7], [8]

There are nine core process workflows in the Rational Unified Process, which represent a partitioning of all workers and activities into logical groupings. Although the names of the six core engineering workflows may evoke the sequential phases in a traditional waterfall process, we should keep in mind that the phases of an iterative process are different and that these workflows are revisited again and again throughout the lifecycle. The actual complete workflow of a project interleaves these nine core workflows, and repeats them with various emphasis and intensity at each iteration. [5]

Would it be possible to evolve our existing PMI methodology using the dynamics of RUP, analogously, the nine core workflows are the nine knowledge management areas and processes? Instead of being in the unidirectional linear waterfall, can the processes be spiral, iterative models? It would need the industry to determine the feasibility. Perhaps some experiments have to be done to provide evidence support.

Conclusion

Dynamics is one area of project management model evolution. In this paper we identified two areas, role dynamics, and processes dynamics, from other management disciplines literature, and discuss how they would benefit project management. By introducing the dynamics factor into management considerations, hopefully modern complex projects implementation can be done more flexible and productive. At the same time the team can achieve higher morale and satisfaction.

Reference

[1] Jonathan C Lee , David McCalman . (2009), Japanese Management Approaches: The Fit for Project Management International Journal of Management . Poole: Sep 2008 . Vol. 25, Iss. 3; pg. 584, 9 pgs

[2] Ricks, D.A. (1993), Blunders in International Business, Cambridge MA, Blackwell.

[3] DeMarco, Tom and T.Lister, (1999), Peopleware: Productive Project and teams, 2nd ed. New York: Dorset House

[4] Project Management Institute 3 rd edition, (2004), A Guide to the Project Management Body of Knowledge

[5] Rational Software Company, (1998), Best Practices for Software Development teams

[6] Michael T. Devlin, and Walker E. Royce, (1995) Improving Software Economics in the Aerospace and

Defense Industry, Technical paper TP-46, Santa Clara, CA, Rational Software Corp

[7] Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaar d, (1992) Object-Oriented Software Engineering-A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 582p.

[8] Ivar Jacobson, M. Griss, and P. Jonsson, (1997) Software Reuse-Architecture, Process and Organization for Business Success, Harlow, England, AWL

The Author

Eric Tse is an international recognized expert/consultant in Enterprise Access and Identity Management Architecture Design and Implementation. He has been working with international renowned experts in information technology in many prestigious companies. He also pursues research interests in project management, financial models, application/enterprise/solution architectures, compilation technology and philosophy of science.

Copyright Project Perfect