Continuous Improvement vs. Project Management

[stormbind]

I am still learning, but with each step things are becoming clearer.

As a developer, I have always advocated Continuous Improvement. Much of the time, this is essentially be powered by the requests of end users.

As a Project Manager, my textbook guides (I did say I was still learning) are trying to distance me from the developers: It is no longer my priority to make sure things work, it is my priority to make sure enough resources have been assigned to get the job done on time.

For me, this causes a massive conflict. How can I possibly advocate Continuous Improvement when time is limited and resources are budgetted?

But surely, I cannot do a 180 and sideline such a fundamental aspect of ongoing growth.

How do I intergrate these seemingly conflicting visions and methods of working?

--Glen

Memoria mihi benigna erit qui eam perscribam

 

[stormbind]

You know the Dilbert Principle: Project Management textbooks seem to be written by that moron manager with the two-spikes hairdo!

--Glen

Memoria mihi benigna erit qui eam perscribam

 

[aquias]

I'll be honest, I haven't taken project management courses, nor have I gone through and read "How to's" on this. I have and do continue to manage major projects that have large impacts on the facilities I am in charge of (the current one being to move all servers from one location to another).

Time and resources are budgeted, they are "controlled" and used to justify your existance, along with the existance of your team.

But, in my opinion, part of any project or scheduled activities should include "maintence" activities. This is how I would incorporate continous growth into project plans, where all resources must be scheduled and accounted for.

It may not be perfect, but it allows you the ability to schedule resources across projects and to provide time for them to update existing software.

I may be very much so off base with this, at least in an "Official" how things are done capacity of project management but that is my thought.

 

[senk1s]

pmi distinguishes as a project being time-limited, as opposed to operations that are ongoing

time can be 1 day, 1 year or 10 years

 

[A0C61ZZ]

Glen
If I understood correctly, you are not able to advocate Continuous Improvement which would be like a bonus to the client users along with the usual work orders requests because you have the PM hat on and not the dev one.

I'm assuming the project you are managing is in maintenance phase.

Which methodology are following for development & PM?
RUP (Rational Unified Process) methodology should be fine as it allows for changes & builds in an incremental manner and you could easily sneak in a couple of "continuous improvements" along with the regular requests.

 

[BNPMike]

The only fundamental, irrefutable difference between management and project management is that a project must be a temporary thing. Thus you cannot have continuous improvement.

This doesn't mean you can't orient yourself towards providing improvments for the client. Soft Systems Methodology is an extreme version of this, where the project goal is simply to move the business from where it is to a better place without any attempt to specify up-front where that might be.

 

[thedaver]

Hang on...

A software project in maintenance mode where bugs are fixed using a change management process IS continuous improvement.

A software project where ENHANCEMENTS, when justified and large enough, are treated as project IS ALSO continuous improvement.

Unless you are treating the concept of "continuous improvement" as a Just-In-Time methodology - which is largely devoid of any change control (a bad thing) then you are inherently (through the two steps above) actively applying continuous improvement.

The pace of progress , of course, is set by a number of factors....
-- Scale
-- Scope
-- Resources
-- Cost
-- Simplicity of change
-- Impact of other changes proposed
-- Customer availabilty to work throughout the project
-- etc...

also

it is my priority to make sure enough resources have been assigned to get the job done on time

I strongly disagree with that being your priority. Your priority is to match the needs of the customer, the available resources, the time available, and any budget constraints together to reach a MUTUALLY AGREED project scope/timeline/budget that describes what your business feels are the most valuable, important efforts to engage.

That ALSO results in continuous improvement...

I'm guessing that BNPMike will now disagree with me...





D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[stormbind]

At the moment, I think Continuous Improvement should be treated as new oportunities that either..

1) can be accomplished with existing project resources, which would make them additional tasks.

2) failing that, they spawn new project ideas for executives to consider.

I strongly disagree with that being your priority. Your priority is to match the needs of the customer, the available resources, the time available, and any budget constraints together to reach a MUTUALLY AGREED project scope/timeline/budget that describes what your business feels are the most valuable, important efforts to engage.

Well, I would not assign more resources than I have at my disposal!

--Glen

Memoria mihi benigna erit qui eam perscribam

 

[BNPMike]

The only irrefutable difference..."
...except thedaver refutes it!!

(Your name is quite close to thecadaver if you follow my drift...)

Seriously, I guess you're right thedaver. A project is irrefutably something that is a new initiative. So it has to have a start but I guess it could go on for an indeterminate time.

 

[ponderworks]

Hold on a second!!! Any project is governed by a Statement of Work. In my experience, too little time is spent hammering out a mutual agreement that sets out what is allowable within scope and what requires a change order. You don't state whether your project is fixed-price or time and materials. In either case, scope changes, bug fixes, or other such things are normal in the course of the project. It is essential that you be aware of these things as they happen and control them. It is a critical part of your job and should make you stay close to the engineering staff.

There is nothing more frustrating to an engineer than endless scope creep! So the idea that a PM should be distanced from development staff under any scenario (or methodology) is pure bunk.

As for continuous improvement, it all depends on what is allowable given the time, cost, and functionality constraints. There is no reason why continuous improvement techniques cannot be applied if the project is managed well. You just need to make sure that you are not endangering the project by doing so.

The main part of your job is to make sure all stakeholders (client, project staff, and users) are made aware of what is being done in their name and they approve of it. Simultaneously, appropriate change control processes should be used. You don't indicate whether the project is using Agile techniques or not but either way, continuous improvement can be a part of a well-managed project.

et

 

[PDQBach]

There is some confusion here but "ponderworks" has cleared away some of it. Let me see if I can add just a little more clarity.

1. A project is a one-off occurrence. It is *not* a process.

2. A project methodology is *not* a one-off occurrence. It is a process which is designed to control how all projects are run.

Some say that the project methodology should be flexible and include continuous improvements.

Some say that the methodology should should be fixed and should only be changed by a project.

I believe both. Non-trivial enhancements (involvement of auditors in specific projects because of Sarbanes Oxley, for example) must be part of a project to revise the methodology because the impact to the methodology is both far-reaching and long-lived. Trivial enhancements (a new template for a statement of work, for example) can be worked in without running a project.

So ... let's look at a project. There are only two constraints on a project (and they aren't budget or time).

The constraints are the project Statement of Work (or Charter) -- which controls the project product deliverables -- and the Change Management system -- which controls the project operation deliverables.

The SoW constrains *exactly* what will be delivered. If it isn't in the SoW (or is explicitly excluded by the SoW) it is not in scope. End of discussion.

The Changement Management system constrains *exactly* how the SoW can be modified. End of discussion.

If you haven't got the first then you haven't got a hope of meeting the project deliverables because there isn't agreement on what is in/out of scope for project and product deliverables.

If you haven't got the second then you haven't got a hope of controlling how the first will be changed which, obviously, means you haven't got a hope of getting agreement on what is in/out of scope for project and product deliverables.

Now, let's look at the project management process. It defines exactly what the project manager must do in order to manage the project. It is, for lack of a better term, the standard of organizational best practices for project management. It is, therefore, the constraints under which a project is run.

 

[johnherman]

OK, time for my 2 cents.
Continuous Process Improvement is a Total Quality Management / Six Sigma / Capability Maturity Model term. See also forum795.

CMM, developed by the Software Engineering Institute at Carnegie Mellon, is probably the best place to start.

CMM rates processes, including Software Engineering, in increasing levels of maturity starting from repeatable processes (standards) and further into the ability to track your performance (metrics) versus industry standards (benchmarks) and to track the improvement of your process all within a regimented process.

Some people (like me) believe that Project Management can be approached using the CMM methodology. But remember, CMM is only a measure of how repeatable your PM methods are, how they compare to others, and how you track your performance and initiate improvements. The guts of the lowest levels of CMM is a repeatable process, which means you must have a standard PM methodology including methods to estimate task duration and effort, dependencies, resource management, etc.

Although related, Continuous Process Improvement (Deming, Crosby, Juran, Ishikawa, and the quality guys) along with SEI's CMM are not a substitute for PM, but rather a tool by which you can improve your PM over time.

-------------------------
The reasonable man adapts himself to the world. The unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw

 

[johnherman]

For further information on CMM, you can also go to this link:

http://sixsigmatutorial.com/CMM/CMM-Intoduction.aspx

-------------------------
The reasonable man adapts himself to the world. The unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw

 

[stormbind]

ponderworks
So the idea that a PM should be distanced from development staff under any scenario (or methodology) is pure bunk.

This snippet reads like an utter breakdown of communication. Personally, I prefer to request disambiguation before hurling condemnation.

I am not a manager deployed in a programming environment, I am a programmer deployed in a managing environment. There is perhaps a huge difference in perspectives.

I feel distanced from developers if I have not contributed to their code personally, or at least witnessed the creation of each subroutine. This does not mean I am unaware of which tasks they are supposed to be working on.

Not having the time to muck in with development, and witness source code changes, creates an uncomfortable feeling of insecurity.

--Glen

Memoria mihi benigna erit qui eam perscribam

 

[BNPMike]

The SoW constrains *exactly* what will be delivered. If it isn't in the SoW (or is explicitly excluded by the SoW) it is not in scope. End of discussion.

The Changement Management system constrains *exactly* how the SoW can be modified. End of discussion.

This is the most common view of a project but in fact is not essential. It is a simplification that linear methods (Prince, PMI etc) use because they can't deal with fuzzy situations.

An example is "The European Project". This is about forming the EC. There is no in-scope/out-of-scope. There is no budget, end date or deliverables. Nevertheless there are millions of people taking an interest and the concepts of success and user satisfaction are just as real as any vanilla IT package upgrade run along structured lines.

 

[thedaver]

Forming a pan-European alliance as a *project* is a gross oversimplification using some dangerous ground to make a response on the original post which, in my opinion, has been been flogged and taken OT.

Can we end this thread or would it be better to create a new forum to debate PM philosophy?

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[zencalc]

Let me add my .02, (and I would like this thread to continue as the topic and contents are quite appropos to the pressures most of us face)...
The SoW signifies what is to be delivered. The project charter assures that the stakeholders and sponsors sign-off what signifies this SoW and the project completion. As PM, once that goal is attained, with due diligence paid to quality requirements; then the project is complete and turned over to operations. Running maintenance processes or coninuous improvement as a "project" becomes a game of chasing your tail to exhaustion.
The PMO tries to use reiterative processes to make the job of project mangement easier and more predictable, not to create the same project over and over. And that's a big point. Even using PM3 or CMM as a guideline for those "controlling" processes, as defined by PMI, for aspects of production or operational work, those operational or maintenance processes fail the tests of temporary and unique. So I'm left with the question of why to even try to CMM as Project Management? Or perhaps my understanding of your original scenario is all wrong.
In either case, flame away!

Brian
Manus manum lavat!

 

[johnherman]

Care must also be taken not to confuse the Spiral Model of Software Development with Continuous Process Improvement. The Spiral Model should have fixed boundaries (SoW and Change (Scope) Management procedures) for each iteration of the spiral. Many novice or lazy PM's use the Spiral Method as an excuse to avoid having to properly manage the project constraints.

I have considerable empathy for stormbind's situation as stated in the original post, having been promoted to Project Leader from within the Software Developer ranks (albeit 15 or so years ago), and it was difficult to keep from sticking my hands back into the code except as absolutely necessary to mentor someone or fix "mission critical" bugs.

-------------------------
The reasonable man adapts himself to the world. The unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw

 

[rvnguy]

Stormbind,

I have been reading your post and the many astute comments to same. Butg when I read your follow up post copies below, I was taken in a different direction by your stated concerns. These seem much different than you Original Post to me.

"I am not a manager deployed in a programming environment, I am a programmer deployed in a managing environment. There is perhaps a huge difference in perspectives.

I feel distanced from developers if I have not contributed to their code personally, or at least witnessed the creation of each subroutine. This does not mean I am unaware of which tasks they are supposed to be working on.

Not having the time to muck in with development, and witness source code changes, creates an uncomfortable feeling of insecurity."

I am a PM for a major corp for facilities installation (not IS/IT ). I feel, from your stated concerns that you have, are having, feelings of trepidation about not being more directly involved in the generation of the solution. I also read that or feel that you do not trust the people involved to accomplish the task without you witnessing the development as this causes you to feel insecure.

I will be blunt: GET OVER IT. or go back to programming and being involved in producing the solution.

"A wise man surrounds himself with those that are wiser than he"

As a PM in my discipline, there is little that I could do to be an expert in all the areas that are involved; Milwrights, mech eng, elec eng, HVAC, and so on. So I must select, and trust the specific individuals to do there job and my charge is basically to insure that the proj stays on-time/budget and meets the SOW.

I feel your pain in not being more directly involved but this is not the charge a PM has. Schedule ample time for shakedown testing/startup test runs and fixes and learn to have confidence in your teams abilities.

rvnguy

 

[fullofquestions]

rvnguy is right on. I moved from developer to PM and suffered the pangs of "Lack of Control". It comes with the terriority. The word you need to become familiar with is delegation...and it means have trust in those individuals that you have delegated work. It is unsettling at first but grows easier with experience. Good Luck