When we look at types of projects we see differences based on project content, size and complexity.
The content may be developing software, implementing a website, constructing a building, putting on an event, creating a new product or enhancing or maintaining an existing one.
Size can be measured in terms of budget, duration, the amount of effort and/or the number of people involved.
Complexity is a function of the number of people and organizations and the relationships among them, the relative uniqueness of the project to the stakeholders, the politics involved, the number and type of dependencies with other projects and products, among other factors.
A large complex software development project might call for an iterative approach, while a smaller one might call for an agile approach. A large construction project would call for a waterfall approach.
People are at the heart of project management. There is a wide range of knowledge, experience and beliefs about projects and project management. Novices, or even seasoned people with little training or experience outside of a small range of project types, are unlikely to have the skills to flexibly and effectively manage without formal process, mentoring and coaching.
Imagine trying to manage a complex project using sophisticated techniques like earned value management without the training and experience.
Beliefs about project management are also a factor. Some stakeholders view project management as a wasteful activity that increases overhead and bureaucracy without adding any value. Others view project management as a rigid set of rules that must be applied to any project no matter it's size, type, complexity or other attributes. There is a continuum of such beliefs. attitudes based on these beliefs influence how project management is applied.
A sponsor who has little regard for project management formality will move the PM towards a less formal approach, but should not be moved so far into informality that it would jeopardize project success. The PM would be responsible for influencing and educating the sponsor while modifying the approach.
When there are effective project management tools and people who know how to use them, the way projects are managed can be quite different then when there are no tools and/or less sophisticated tool users. Systematic use of a toolset such as Microsoft Project and SharePoint makes it possible to automate work-flows that reduce the effort required to mange issues and changes, control the project and communicate among stakeholders, but the users have to be skilled in the use of the tools, their process has to be well tuned and the tools have to be tailored to the needs and sophistication of the users.
When we look at all the potential variations it highlights the need for situational management. We need to apply the right level of rigor, discipline and formality to get the job done. we want to take an approach in which there is no excess and no insufficiency.
Examples of excess are requiring unnecessary documentation that adds no value, doing estimates at a level of detail that requires more effort than is needed, collecting too much data and not using it effectively, over reporting, too many meetings, over control of changes and issues in an informal environment. Excess is wasteful, it costs too much, takes too much time and makes people think they are spending too much time on administrivia rather than on performing productive work. When creating the communications plan and deciding how to plan, control and monitor the project ask, why will I do it that way? What value will it add? Is it in keeping with the capabilities of the stakeholders?
Insufficiency increases the risk of project failure and sets up bad habits. Examples of insufficiency are lack of regular reporting, change and issues control that relies on personal memory rather than documented information, plans that do not provide the detail needed to effectively manage, tasks defined without deliverables, etc.
Who is responsible?
Who decides on the approach? In some settings the project manager has the autonomy to establish his or her own project approach. Generally, this is the case in organizations that are relatively immature, where there are no project management standards and procedures. In more mature organizations the project manager would be expected to craft the approach from an existing methodology that contains models for different types of projects. In some organizations the project manager works with a project management office to craft the approach and must receive authorization from the PMO before proceeding.
Under any circumstances, it is the PM's responsibility to go beyond personal preferences and select the kind of process that suits the project. That means if the PM likes Agile and the project is large and complex and calls for more of a waterfall approach, that the waterfall approach should be the preference.
Taking the time to engineer a PM approach that is based upon the combination of existing standards and best practices and the specific characteristics of your project will contribute to a greater probability of success.
To accomplish this,
- create a taxonomy of the projects you do, addressing their content, size and complexity
- establish models, standards and procedures for each type; use your own past history as a base
- profile the people to identify their level of knowledge, expertise and attitudes
- make the effort to educate and reorient the stakeholders to make the environment more PM friendly; provide support
- assess the need for tools and choose ones that can be used with varying degrees of sophistication across a wide range of project types; provide training and support
- manage projects and assess the need for improvement based on the results, measuring stakeholder satisfaction, compliance with scope, schedule and budget and the degree to which benefits are delivered.
Don't forget to leave your comments below.