Flint, in an earlier thread you made some derogatory comments regarding my planning skills. Please let me clarify a point. I did say that I have planned and scheduled "thousands" of projects during my career in project management. I also said that none of these projects (of any complexity) met the original schedule date. It is obvious that you don't have any in-depth experience in project management, and I may have mis-lead you by making such a bold statement, so let me explain a little.

In a large organization, a planner is not a King. A planner is not all knowing. A planner is usually a member of a project team that includes a project manager and representatives from functional departments such as engineering, procurement, etc. A planner develops a plan and schedule based on input from other team members and scope of work documents.

There are many reasons most schedules don't meet their original schedule completion dates. Some of them are: scope of work not clearly defined, budget constraints, not enough time allocated for planning, weak project organizations, weak project managers, low company priority, lack of upper management support, unrealistic activity durations, inexperienced personnel, shortage of personnel, individuals giving lip service to schedule compliance, weather conditions, and political climate... I could go on, but I think you get my drift.

During my career, I've worked in some exceptional organizations and some bad ones - the good, the bad, and the ugly. The point I would like to make is even in the best organizations, they usually didn't meet the original schedule completion dates. Please note that I'm talking about the ORIGINAL SCHEDULE completion dates. As the scope of work was better defined the revised schedules were usually met.

The point I was trying to make is that complex projects usually don't meet their original completion date. In my experience that is a fact. Is it something to get upset about? I don't think so, it is just the nature of things and should be planned for. What does this mean in terms of the real world? To me it means that Y2K remediation should have started many years ago for most large organizations to allow time for scope defination and schedule slippage. The Social Security Administration started early and will be OK, but those who didn't won't make it.

For a large enterprize organization, Y2K is a planner's worst nightmare. To ensure work is accomplished, each detail activity must be planned and scheduled. This is almost impossible to accomplish since you need a multi-tiered schedule that covers your company's suppliers, their suppliers, their suppliers suppliers, and so on. To ensure the schedule is met, periodic progress reports are required. This means that you need status from all of the elements in the multi-tiered schedule. Let's define supplier's as anyone external to the enterprize. For Y2K these will probably include vendors, subcontractors, utilities, customers and clients. Note: I'm not just talking about code remediation. In the real world it would take an army of planners to just define and schedule these interfaces, so it just isn't going to happen.

What choices does an organization have when they set up their project plan? Very few. They must hold their first tier interfaces accountable and set up a reporting system. They must trust that the people reporting to them are reporting truthfully, and the people reporting to the first tier are also reporting truthfully, etc., etc.

What does this mean to me? It means that I think it is impossible for many companies to complete their Y2K projects in time unless they started early, and are using proper project management control techniques.

Flint, my area of expertise is project management. I believe yours is electronics. I tend to trust what you are saying (sometimes) because I don'nt have the expertise to dispute what you are saying. However, in the final analysis, we all must make decesions based on our expertise and experience. I have over 35 years of project management experience and based on my experience I am preparing for Y2K. We all tend to project what the future will be based on our analysis of past and present events. So I will stick with my original statement and tell you again: " I have planned and scheduled over a thousand project and don'nt recall any (of any complexity) that met their original schedule completion date."

-- Watcher5 (anon@anon.com), April 29, 1999

Answers

Watcher5, pay NO attention to Flint, he is a master of "Double Speak" and disinformation. You will waste your time trying to reason with him.

Ray

-- Ray (ray@totacc.com), April 29, 1999.

But you are ignoring the fact that most original plans were scheduled for completion at least a year ahead of 1/1/2000! If we KNEW that slippage in every case was less than 11 months, we could all go fishing and forget about it. Now some won't get done before then - which makes the question of what they HAVE finished important. As a planner, you know the critical core functions would be scheduled first. Any other assumption would involve assuming the planner was not competent to understand the possibility of time frames slipping. So a company that has a competent planner has a very good chance of weathering the Y2K storms, EVEN IF EVERYTHING IS NOT ENTIRELY COMPLETED.

-- Paul Davis (davisp1953@yahoo.com), April 29, 1999.

Watcher5, none of the thousands of projects met the originally scheduled completion date? Wow.

I don't mean to sound disrepectful, but it sounds like some project management methodology changes might help. All of your points are valid, but in my experiences in project management, the project teams work diligently to improve the process with each project.

For example, in my first job as a project manager, we consistently failed to meet deadlines and delivered flawed products for the first year or two. During that very frustrating time, we developed our estimating and planning skills to the point where each project was incrementally more successful both from a quality and delivery date perspective. By the beginning of the third year, we were consistently hitting our deadlines and delivering high quality software for the following three years. I moved on to a different company, but subsequently learned that our project team had evolved from a level 1 organization in the Capability Maturity Model to a level 4 organization in a matter of 5 years. The improvements took alot of blood, sweat and tears, but it was well worth it.

-- David (David@BankPacman.com), April 29, 1999.

Paul Davis said: "But you are ignoring the fact that most original plans were scheduled for completion atleast a year ahead of 1/1/2000!" That was when they were planning to have the *remediation* completed, not the remediation + the testing, which is what is required. And that deadline just sailed on by.

Paul Davis said: " As a planner, you know the critical core functions would be scheduled first" They've already thrown to the wind the majority of functions, and are only bothering to fix mission critical systems. While, yeah, they're probably fixing the most critical ones of these first, they were all pretty important to begin with, hence the name "mission critical" I guess.

Paul ..... give up.

-- humptydumpty (no.6@thevillage.com), April 29, 1999.

Paul, I'm trying to figure out what you said and I'm having trouble. You said I was ignoring the fact that most original plans were scheduled at leat a year ahead of 1/1/2000. You are missing my point. Most large enterprize organizations did'nt start early enough. The social security administration started in 1989, they did'nt declare victory until early this year. I believe they had 60 million lines of code to remediate. I know of several large enterprize organization that have simular amont of code that did'nt start until March of 1998. They will not make it.

The critical functions are always scheduled for completion before the non-critical ones. You said any other assumption would assume the planner was not competent. If a company did not start in time, it really does not matter how good the planner is. For your infomation, the planner does not set schedule completion dates. That is a management function. A planner is an employee or a consultant. he can voice an opinion, but in the final anaylsis, management runs the show. Did you get that last sentence, Paul, it's management's show!

And now to answer David. My experience is planning and scheduling has been with large scale development projects. I started my career as a PERT Analyst developing Ground Support Equipment on the Apollo Space Program. I was a principal planning specalist on the Sky-Lab Program. In this capacity I scheduled hundreds of design mods to the Sky-Lab. I was a Master Scheduling manager on the Lance Missile Program. I have particpated in numerous planning and scheduling complex construction projects. I was an Outage Planning Consultant Southern California Edision on their San Onofre nucler plants and to Florida Power and Light on two of their nuclear power plants. Anyway, David, I'm talking about my experience on large complex projects. I am not talking about honing skills on repetive IT projects in one company. I have to agree with you, if one planned and scheduled the same type of activities over and over again, one should expect solid results after a while. As you said improvements, took a lot of blood sweat and tears but it was worth it.

Let me repeat myself: I'm talking about the ORIGINAL schedule completion date.

-- Watcher5 (anon@anon.com), April 29, 1999.

Watcher5:

Sorry I can't reply during the day. I'm permitted to read but not write.

When I tried to translate your statement into my world, it came out like "I have programmed thousands of devices, and every one of them failed toperform as specified." And in my world, this would be unacceptable. The fact that plans and schedules miss their targets every time and are still considered acceptable in your world continues to baffle me. And I read your explanation very carefully.

I can understand that large projects are extremely complex, and that they rely on many different estimates. But I wonder if that isn't missing the point. Many of my projects also rely on others doing their work correctly. And I have indeed encountered technical problems that render my task impossible *as originally specified*.

Recently, I was asked to make a very nontrivial enhancement, basically to port existing code to a different board design using very different interfaces based on homebrewed support chipss. My estimate for the job was 6 weeks. So I was asked if I could get something at least up and limping in 2 weeks. I replied that I could do this, but it would probably take 20 weeks to debug. It's stupid to try to slap out code to live in a complex asynchronous environment without first very carefully analyzing that environment. But I was told "that's OK, we don't expect any problems with this thing."

Sure enough, the 2 week period got built into the schedule, to be followed immediately by tasks requiring a debugged system! So right now, we're in the 6th week of debugging, and on hold because the equipment and personnel required were scheduled for a different project at this time. We weren't expected to need them! The problems lie with the hardware, which was designed without input from the firmware side (me) because on paper it was faster and cheaper to do it that way.

Now, I knew this would happen. I told the planner and scheduler this would happen. The 2-week period didn't come from me, it was imposed on me externally. Why? Turns out prior steps had taken longer than anticipated (imagine that!) and there was only 2 weeks worth of money left in the budget for my step in the process. Sheesh.

I've been through this too many times to count, just like you. From my worm's eye view, it seems that marketing sets the original schedule, and they want it done yesterday. From there, it goes to finance, and they decide it *ought* to cost half of what these things have always cost in the past. Why? Because something unexpected always came up in the past, but it won't happen this time, see?

From there, it goes to someone like you. You have half the necessary time and budget to work with, so you tell those whose sub-estimates are input to the master plan, what their limits are. Sure enough, these people produce estimates matching those limits. What else can they do? They know it can't be done in that time, and they know that when that time is reached, the project will be either killed or delayed. And what difference does it really make anyway? Nobody is being incompetent or lazy, they're working as hard as they can and it takes the time it takes.

From the engineer's standpoint, this is an ongoing joke. The PHM's always ask for the moon, they never get the moon, and they never learn. Or maybe the PHM's don't *really* expect the moon, but continue to believe that if they set unrealistic goals, these projects will ultimately end up finishing sooner and cheaper than if the goals were in fact reachable. And always, the project takes *longer* than a reasonable schedule would call for because the necessary resources for each stage in the project were scheduled for earlier than they were needed, and aren't available when their time comes. Or because there's never time to do it right, but always time to do it over.

I should think that after missing the target thousands of times over the course of 35 years, you should have developed some sense of how long things take and maybe even developed a little feel for what sorts of pressures lead people to make unrealistic estimates.

I've learned that managers might *ask* for a time estimate, but that's not what they want. They have a known impossible maximum time and they want me to guess what it is. So I end up having increasingly unrealistic 'estimates' kicked back until I hit that target on paper, after which it takes me the time I originally estimated to do the job.

And this is how projects never meet the schedules. It's not the planner's fault, It's my fault because I was unable to meet 'my' estimate! Phooey.

And yes, I expect many y2k remediation projects to be late for these same reasons. The poor planning is happening because it is NOT being driven by the technical requirements of the task, but rather by getting too low a priority from the money people.

-- Flint (flintc@mindspring.com), April 29, 1999.

Flint, Thanks for your reasoned and well thought out response. I rest my case.

-- Watcher5 (anon@anon.com), April 29, 1999.

I humbly bow to your experience sir. My 10 years in IT project management doesn't hold a candle to your background. In fact, for those who do not know, NASA is the only organization to hold a CMM level 5 designation and is widely considered the ultimate in project management and execution.

Question, in your opinion, does the typical Y2K remediation project more closely resemble a repetitive IT project that should be within the realm of a finely honed project team to accurately manage and estimate or is it closer to a complex construction project whose deadlines are more elusive?

My guess is that it's a little of both, but for most industries, it more closely fits the repetitve IT project model.

-- David (David@BankPacman.com), April 29, 1999.

David,

Thanks for your kind words. I was fortunate enough to work on two major NASA projects. In retrospect, I have to agree NASA certainly had it's act together regarding project management. For reasons Flint spelled-out my experience in other sectors were not that pleasent.

You asked about a typical IT project and wheather it could be in the realm of a finely-honed project team to accurately manage or would it compare to a large complex construction project. The answer is yes, and no. I don'nt think it is all that difficult to scope out and plan and schedule JUST the remediation of code on a Y2K project. The rub comes in when you try to develop detail schedules for interfaces beyond your control, such as electric utilities. This is what I had in mind when I said planning and scheduling a large Y2K remediation project is a planner's worst nightmare. There are two many interfaces. There is no master schedule.

One of the things that bother me is the fact that it takes years for a company to aquire effective project managemnt skills. Most Fortune 500 companies have limited project management experience. Now couple that with all the reasons that schedules are not met, and you can see why I'm not optomistic about companies meeting their Y2K deadline.

-- Watcher5 (anon@anon.com), April 29, 1999.

David -

You might want to attend a project management conference sometime soon (say, ProjectWorld, or one of the get-togethers put on by the Project Management Institute). I saw the results from a recent questionnaire of conference attendees about their company's PM processes. They reported little management support, no understanding of project sponsorship, minimal confidence in estimates, poor status reporting processes, you name it. Sad, really sad.

Re NASA: not to take anything away from them, but it would be interesting to see if they would be assessed as Level 5 now. It's my sense that they're lost some of the hard-nosed commitment to process that got them to Level 5 originally. Entropy affects an organization much like any other system.

And unfortunately, CMM Level 5 didn't keep the crew of the Challenger alive once someone "put on their management hat"...

-- Mac (sneak@lurk.hid), April 29, 1999.

Excellent points Watcher5 and Mac. In rerospect, I recall that half the battle in achieving the improvements that we did had to do with "training" our senior management to let us manage the projects and to trust our decisions. It took the backing of a strong executive VP in our corner to convince everyone, but once we were allowed to do our job the way we knew how, things were better for everyone.

Of course we had to work with management directives, but all too often, management wants to dictate deadlines, resources and project content/requirements before a single estimate is submitted -- no room to wriggle so to speak. And as you know, the only thing you can work with to complete the project within the invariably unrealistic deadlines is to compromise quality by using shortcuts.

When I initially read reports that the President imposed universal deadlines of March 31 for all Federal agencies to be compliant, I was thinking of all the poor project managers on the receiving end of that commitment and glad I wasn't one of them.

-- David (David@BankPacman.com), April 29, 1999.

I wonder why Paul Davis didn't responed to Watcher5's comments?

-- Curious (anon@anon.com), May 01, 1999.