Project Management Central
|
Please login or join to subscribe to this thread
|
||||
|
||||
Network:648
That is simply General Systems Theory dating back into at least the late '60s.
Systems may be abstracted at many different levels depending on where the boundaries are defined. When many people consider projects, the system of interest is some product delivered to an end customer customer. When the project is developing new business processes and tools to create products themselves, the system includes the people doing the work, and how well the solution fits the business needs of the organization, in addition to the end customer. What PMI calls Organization Process Assets (OPAs) are also sometimes called "enabling architecture" as they are the business/production system architecture that enables the product development. The biggest difference between PM and systems engineering in my mind is where the practitioner defines the boundaries of the system they are managing.
Uppal's definition fits my way of thinking and general approach to management and I recognize that companies invest a considerable amount of time and money in tools and techniques designed to improve management performance. Where I have issues is when companies design approaches including tools and processes independent of project needs and then wedge the projects into those tools and processes (square pegs into round holes).
From my perspective the Project Plan should involve analysing how best to deliver the project selecting from proven and innovative processes and tools rather than "how are we going to fit this project into our preconceived management approach and/or standard operating procedures. Now, I agree that standardization can reduce risk but it also chokes innovation. In my mind the management tools and procedures should evolve from the risk management process designed to best deliver the project.
I'm with Keith on this one. It used to be the project's "system" was bound by it's deliverables. There is an attempt to expand a project's system to also include realized benefits. The problem with this project system extension is that those benefits often take years, after project completion, before being realized. To me, benefits realization should be part of a system that is not temporary, such as the program or portfolio management system. Of course, that presumes the PgMO or PfMO live longer than their current average life span of 2-3 years.
|
||||
Please login or join to reply
ADVERTISEMENTS
|
Disbelief in magic can force a poor soul into believing in government and business. - Tom Robbins |
