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

 

[rvnguy]

stormbind,

Additional note: KUDO's to you "stormbind" for realizing and sharing your personal feelings on this matter. As in most everything; admitting your real problem is the first step to finding a solution.

You have definetly self-observed what your feelings are in this and again I think we all feel your pain.

As, fullofquestions, and myself (and probably many others) started out as solution providers (hands on) and migrated to managing projects and have felt the dismay of not being more directly involved. Especially, in the areas where you have expertise, the tendency is to second guess the methods/approach being taken. Please, don't do it openly. You can't control your feelings here but you can control expressing it. If you must, there are methods to "direct" inconspicously, the actions of others, but this is touchy ground. Better to allow others to develop in their own way as long as the result is satisfactory. You might learn something along the way. Yes it happens.

rvnguy

Hope that you are still following this!!!

 

[zencalc]

Right on rvnguy;
when managing others; and their work, one needs to keep in mind the differnce between perfectionism and what's acceptable. For many of my team members' tasks, I've often felt I could do a better job. But then I have to ask, at what point does the job of project manager turn into "control freak"?
Keep your team focused, find AND COMMUNICATE a useable acceptability standard that your team members can attain, and then do your best to foster an environment that allows bright, creative people to do what they do best. Incidentally that often means you take the bullets from upper management for them!
BUT... if you build that kind of trust with your team, you won't have to question whether they're giving their best effort for you, you'll believe it!
As you do more and more project management, with more complex teams, you'll discover that project mangement isn't about managing the tasks... its about managing your team to perform the tasks. Build a level of trust and support with them, and then stay out of their way. In turn you'll evolve from a task manager to a leader. and THAT can be very satisfying!

 

[rvnguy]

fullofquestions and zencalc

Thanks for the support and concurrence...being a bit egotistical myself, I know trhat I am right on this but your concurrence is appreciated.

It does not appear that "stormbind" is still following this?? Are you still there?? I am sure that you are and I am certian that all of us (PM's) are with you 1,000% in your transition. It is a difficult move for most of us.

rvnguy

 

[stormbind]

Oh wow! I had not been on Tek-Tips for quite some time and was highly surprised to see this thread still active.

Thank you all for your tips and support

To post the chronology of past events would be going off topic, so I'll just say that right now I feel rather apprehensive about taking on another project, at least until Tandy begin stocking affordable artificial hearts..

It was an experience, and I'll never see the world as black & white ever again (it has a kind of grey spaghetti-pattern)

--Glen

Memoria mihi benigna erit qui eam perscribam

 

[grooke]

I have just returned to work and spotted this thread. It is very interesting, if not a bit conventional. I have only had a minutes scan of the replies, a lot of which seem very good within the context of conventional management.

PDQBach gave an excellent reply, but there were many others. One frightened me was the one that said that if you work in a certein way, 'you can always slip a few features in'. This in my book is a complete No-No. The project manager has to keep the project sponsors exactly informed of what is happening.

In my experience, all the best projects (and a high percentage of those that survived through to completion) were very flexible in their approach. I have actually run some very large projects with a considerable element of flexibility. It just needs to be monitored (and to some extent controlled.

Let me now be totally extreme.

'Agile Projects'.
PDQBach quotes significant project constraints are:
[ol][Li]Budget[/Li]
[Li] Timescale [/Li]
[Li] Specification-SOW [/Li]
[Li] Change Management [/Li][/ol]

Now, if changes are occurring all the time, then the change management system MUST be very flexible and responsive, so that the SOW ALWAYS tell what is being produced. None of the 'slipping' something in nonsense. Given this, we only have the first three of the above issue to plan around.

Normal (Waterfall) approach.

Normally, the Budget is the overriding constraint. 'Any greater cost and the project will be canned!'
Time scale is also set although this is more variable (can be stretched). Where does the extra money come from? Well there was more in the Budget than the management let on. It is a matter of bluff and double bluff, and it is this that causes people to think they can 'just slip things in'. The Project Sponsor is seen as the 'Enemy'.

When the Budget really does run out, then the spec gets cut at the last minute. Whatever cannot be finished within a few weeks is not in the SOW any longer, even if it is a very important feature. Often 50% of the features are not complete; well they are all around 80-90% complete, but there is no budget left to finish them. If the missing items are critical to the system, a decision then has to be made whether to extend the budget or 'can' the project. The former puts the Project Sponsor over a barrel, where they would rather NOT be. The second wastes a lot of good money.

Agile Approach.
We set a genuine Budget and Timescale. There may be hidden contingency, but that is less important now, because, 'come hell or high water' the project ends when either the budget or timescale run out. The key constraint is normally the Budget, but the timescale is usually set as the fixed end date.

The spec is identified just as a list of 'use cases' (things the users want to do). These are prioritised in the usual manner and are then presented to the project as a prioritised list, without any selection of what is in scope and what is not in scope.

An 'inception' phase is set up to set up the team, their working environment etc. During this period, the Business staff, BAs and Designers put their heads together and come up with a broad description of what the first few use cases involve and possible a design for the 'Happy Day' scenario on a couple of them. Certainly NOT at a 'Sign Off' quality. The Developers have decided on a system and architecture, development tools etc.

This is then followed by a sequence of fairly short 'elaboration' phases. For each of these, the developers decide what they can produce, and then set about doing it. During the phases they can consult with the Business/Design staff to ask questions, which can even be 'Wouldn't it be better if it did X instead of y?'.

Their task is to produce something workable at the end of that itteration. The user can then change it, add features etc, as long as they stay within the defining use case description. The developers then add these feature, plus some alternate path scanarios during the next itteration and so on. Soon, the key features of the project are working and the Business has 'slipped' in many good features.

Delivery time arrives. What we have is most of the key features working, better than we could have every specified them. Other less critical features are barely started. Because of the Pareto Rule, that 80% of the value comes from 20% of the functions, half the system may not yet have been built, but over 80% of its key objectives could be met.

Now the Project Sponsor is NOT over a barrel. They have a working system, possibly with reduced functionality, but enough functionality to avoid the 'Canning' decision. Also, it is now very easy to see exactly what any extended budget would achieve. There may be 6 features out of the remaining 20 that would make a significant difference, the the other 14 can be scrubbed, unless, they can be 'slipped in'; The team MUST however complete the 6 important ones.

This cannot be achieved without some excellent project management.
[ul][li]That 'list of use cases' must be maintained very strictly; Change Requests at a very high level, but fewer than using formal specs. [/li]
[li]The work to be done in each itteration is very flexible, but it MUST be testable. Write outline acceptance tests as the spec.[/li]
[li]Another thing that needs to be managed, is the rationing of time. The Business/Designers must be aware of the cost of bells and whistles. "Too many and you dont get item 15 in the list"; but they decide whether it is worth it. [/li]
[li]So the manager MUST monitor the speed of progress down the list and keep all parties informed.[/li][/ul]

I have worked on 4 projects that were a bit like this (three of them declared they were using this approach). It certainly made a difference concerning the moral in the team (the team includes the project sponsor; they are no longer the 'enemy'). The one with the least formal project management was a great success. The others were stilted, with the project managers still trying to negotiate the next itteraation with the sponsor, and NOT with the developers. Also dont try it on a team of ex mainframe, formal methods staff. A number will leave, a few die of shock and the rest will still be sitting at their desks having done nothing but shake since the project started.

Good Management is the key to success.

The key thing is to stick to the plan; 'What plan?. Well
[ul][li]the end date,[/li]
[li]the prioritised list and [/li]
[li]extrapolations for the speed down the list. [/li][/ul]

Even if, when you hit the end date with only 20% of the system complete. Deliver that, because it should ALL work.
If it is NOT enough to go operational with then you have a good measure of the real cost of the project; it can continue or be 'canned', but this judgement is made with much stronger information than with the Waterfall method.
If it is enough to limp along operationally, then the method worked, and you get the credit. The project sponsor just has to decide how much more money would make it a reasonable system.

Gil

"Why is it that the one item that we rarely see on a list of risks to a project, is the 'Project Management'? " ;-)

 

[jcasetnl]

In my experience, having worked in both environments, it is extremely difficult to achieve project goals and continuous improvement goals. Conceptually, a project is called a project so that it can have a clear beginning and end, and a resultant product that can show ROI and all that good stuff. It almost has to be this way. A project can affect so many areas of the organization which may be in disrepair that the project itself can be completely hijacked in trying to resolve the deficiencies of the others. Continuous Improvement is hollistic. Project Management treats the symptoms and moves on.

Continuous improvement is difficult to show on the bottom line. It's like trying to explain how the bottom line is improved as a result of the janitors emptying the trash every evening.

My advice, and what I have seen in the real world over the last five years - customers are so bottom line and milestone-focused, your best bet is to always be supportive of your staff's efforts at improvements but never put that ahead of or in place of project goals. At no point do you ever tell staff that it's not something they shouldn't care about or their deliverables will go to hell very fast. But at the same time, they will occasionally be in your face waving a lousy solution asking you to tell them the priority.

I think this grey area is one of the most difficult aspects of project management.