The End Game: Jerusalem Light Rail

The Jerusalem Light Rail is once again in the news: The drivers all had temporary licenses - all of them expired 3 days ago. Only 12 of them have been renewed. Somebody forgot to take care of renewing all of them...


So now we have the train running once every 30 minutes; even at once every 4 minutes it was crowded...


The Jerusalem Light Rail project is a fascinating one to study; it was running way behind schedule and budget until the current mayor Nir Barkat took charge.


His first question :Where's the schedule and the Project Manager? Yes, he comes from the world of software. :-)


The answer? Well, hum, there were a lot of people in charge; one for the infrastructure, one for the electricity, one for the actually trains, one for the software, one for the traffic lights and the list goes on. But there was nobody in charge of everything.


Result: Everybody could blame everybody else for delaying the project. (The initial launch date was January 2009!)


Nir changed that, and the project started moving. When the August 19, 2011 deadline loomed large, those involved started their old story about not being ready. Nir wanted to know what wasn't ready.


The billing system? Too bad. The train will have to be gratis until you get that one right.  Apparently the system crashed when it was tested in real time; lots of people buying tickets all over the city at the same time. Would make an interesting study in design and testing.


The obvious advantage is that the trains are free, meanwhile. The disadvantage is that they are full to capacity, as every loafer in town - and all bored kids - spend their time on the air conditioned trains.


The traffic lights are not synchronized yet with the train? Too bad. They will have to stop at the red ones. (It's really pathetic; at the main bus station there's a traffic light for pedestrians to cross the rails. It's not synchronized (or needn't be) with any other traffic light. Yet the train often has to stop, since it's green for the pedestrians - all of 10 feet from the train station!) 


Supposedly they are working on this project; hopefully not the same people in charge of the licenses.


How they plan on synchronizing the traffic lights for the train without grid-locking vehicular traffic is  not clear to me. I'd like to believe that there are experts on this subject who know better than me.


The trains sometimes run off the rails? This was discovered in high-speed testing. Solution: Drive slowly until we figure this out. Makes one wonder why the rails are needed...


The advantage is this even if you can see the trains approaching, you will often manage to get to station before the train, since it also drives slowly and also gets stuck at all the traffic lights.


Lessons for Project Managers:

• Without a single Project Manager in charge of everything there's going to be chaos. Each major element can have its own Project Manager, but they all have to report to a single person.
• Ship as soon as something is ready; early users are as good as beta testers.
• Ship often, with minor improvements.
• Not every "bug" or "issue" is a showstopper and a reason not to ship.
• Think of creative solutions. Sometimes the experts know too much, and need to be overridden. 

There's probably more obvious lessons; feel free to add them in the comments.


In a future post we'll discuss how Egged rolled out the CityPass; enabling single payment for both trains and buses.

- Danny Schoemann

Prototype pitfalls

In software, a prototype seems to work like the finished product. In reality it's usually a pretty face (GUI) with minimal functionality.


If you actually try use the prototype you will discover that it only works for a limited set of actions, if at all.


My first introduction to a prototype was in the mid-1990's. My good friend Jack Kustanowitz arrived at Kivun (of Dagesh fame) as a summer intern. 


Netscape had just released the first Web Browser - and all you could do was browse. Maybe it also had a back button that went to the previous page.


Using Visual Basic, Jack created a prototype of WebTamer; everything your browser needed. Functionality like "History", "Off line browsing" and "Bookmarks".


And it seemed to work! Making a product out of it should be trivial, Project Management was assured. (These were the same non-techie Project Managers from yesterday.)


Suffice it to say that the road from Prototype to Release was long and painful, since the prototype was mainly a GUI; a pretty face, and Jack-the-wiz-kid was back in college.


Prototypes of the graphical interface are easy to create, very impressive and very misleading to Project Management - and Management in general. It's hard to see why a product which looks ready-to-use will need months of development before it can be shipped.


Sometimes a prototype is used as a technical proof-of-concept. Being unsure of the capabilities and limits of certain technologies, a team will implement some functionality with technology they have never used before. Usually some new emerging technology. 


They can then measure:

• How long did it take? Does this seems like a faster way to implement features?
• How stable is it? If we stress the application does it crash or slow down?
• How fast is it? If they implemented existing functionality, they can benchmark it to see if it's faster or slower than the existing implementation.

In this type of prototype, the important functionality will be there, but the GUI may be missing. 

Can the prototype code be used in the end product? Sometimes; often it cannot as the prototype will have been done without a technical design;  that crucial design stage that ensures that multiple programmers can safely and efficiently work on the same code.

What a Project Manager needs to realize is that prototypes - both types -  are not an indication of a finished product, no matter how good the demo looks or functions.

The connection between a prototype and the end product is often similar to the connection between an ad and the actual product, or the trailer of a movie and the actual movie. You've been shown the highlights; the devil is in the details.

Lessons learned:

Having a "working prototype" will not in any way shrink the schedule. "It's almost ready" is not true.

A prototype does not absolve the Project Manager from creating a fully blow functional specification document. Assume all the functionality is missing. What you see in not what you will get.

Why a technical Project Manager?

Is it important that a project manager understand the technicalities of the project she is managing?


In theory Project Management is all about scheduling; finding out what needs to be done, how long it will take, and tracking the results.


There seems to be no reason why the Project Manager needs to understand the technicalities of the project.


I have discovered that this is not so. A Project Manager who does not understand the technicalities, has no idea what she is doing.


Firstly, the team loses all respect for a Project Manager who cannot differentiate between a check-in, a compile and a debug session. As a result they have no problem hiding information from the Project Manager - a guaranteed recipe for disaster.


Many years ago, before I became a Project Manager, I attended the daily meetings of a project, as manager of setups (the installation program).


In the engineering department I was hearing them talking about rewriting the Kernel - that's a huge job and is like a heart transplant.


In the daily meetings I was hearing the engineers inform the Project Manager that the project will ship on time - a few days hence.


Six months later the project was almost ready to ship, and I was convinced that I wanted to become a Technical Project Manager.


Had the Project Manager been technical, she could have asked what the team is up to, and understood that rewriting the kernel is going to be a long task.


Another reason for a Project Manager to understand what technologies are being used and what they do, is in order to catch inconsistencies as early as possible. As an objective bystander (after all, she is not going to write any of the code), she may often see issues which the people involved do not realize.


I have also seen ex-programmers turned Project Manager help come up with great (and simple) technical solutions; sometimes the people involved in the work do not see the forest from the trees - and a simple solution is best.


In my experience, I find that I can estimate the scope of a project before discussing it with the engineers. This way I can tell if the engineer is guesstimating in the correct ball-park, or if she is way-off. I can then discuss with them what they base their estimates on.


The Project Manager is more than the conductor on the bus, who does not need to know how to drive. She is also not simply the air-hostess who needs to ensure everybody is comfortable, but will never need to fly.


An efficient  Project Manager needs to be a co-pilot; somebody who is aware of the meaning of all the pieces involved.

To be wise or to be right?

Yesterday I was watching a group of kids trying to define an ad-hoc game. They had about 15 minutes of play-time at their disposal.

Most of the kids just wanted to play and make up the minor details as the game went along.


There was one girl who was strong willed and was insisting and defining every possible rule - and she had a strong opinion as to what those rules should be.


Result: They spent the entire 15 minutes defining rules. Not all of them; some of them left earlier in disgust and went to play.


There's a delicate balance between a fully completed  spec and a perfect one.


This is one of those tough calls that a Project Manager has to make. The spec most cover everything. Or must it?


My father tells the story of how the programs in his time - coded on punch-cards (!!!) were able to handle leap years - including the exceptional ones - like the turn of the century. Their systems were Y2K-proof.


After all, they had no idea that the world would progress past punch cards - so the date formula was written for posterity.


At the time it was probably the best decision: the date formula is used all the time and adding an extra condition in the code was not a big deal.


After a spec is written, there is a spec-review meeting - where all those who will be involved in the implementation and testing should be invited; attendance is conditional on having first read the spec.


At those meetings there will be some heated debates about missing features or how to implement seemingly trivial functions.


The key is to listen carefully to what is not being said. Very often one of the vocal (loud or insistent) reviewers of a spec has a hidden agenda: e.g. a pet concept or implementation that they want to use - or learn how to use.


Or a skill set they want to use. Or a fear of the unknown. Sometimes it may be a (self declared) expert who (erroneously) thinks she needs to have original input to everything, otherwise she'll lose her job.


Sometimes it is a simple case of "Perfection is the enemy of Completion".


A trick that I learned for all meetings that get side-tracked or are taking too long: After 30 - 45 seconds simply interrupt the interruption and say "let's take that off-line".


Write it down and make sure to follow up (usually with an email, to as few people as possible) - otherwise they will stop letting you use that line. 


Often the follow-up email will be the end of the story. After all, the proposed concept was only to gain attention during the meeting and not to actually try improve the spec.


Sometimes the ideas being suggested are correct - but will kill the scope of the project. Be realistic about the life expectancy of the project. 


besides, it's often best to ship a feature-free product ASAP and then - if it's a success - to release frequent updates.


It's better to get requests for more features rather then complaints about poorly implemented features.




- Danny Schoemann

Setting priorities

In Agile development, milestones are typically 2 -3 weeks long and are called sprints.


Before each sprint, the team gets together and decide what needs to be done. Typically, the Product Manager will have a backlog of tasks from which to choose from.


Obviously, urgent tasks that will make a noticeable difference to income, traffic or user experience will get priority.


However, less-important tasks also need some attention, otherwise they will never be done.


The date at which a task was first presented to the sprint-prioritization meeting should be noted. If a task has been presented 3 or 4 times and is still in the queue, then a decision needs to be made:
Either do the task in the coming sprint, or delete the task.
If a task is simply being mentioned for old times sake, and everybody would like to do it but nobody has the time, and nobody can see the urgency, then it is simply taking up time in the prioritization meeting.


Since we live in a dynamic world, not every task can be planned 2 - 3 weeks in advance. That is why a typical Kanban board has more lanes:

1. Emergencies and Showstoppers. 
• Either the live system has become unstable (e.g. web site down,under attack or slow) or a 3rd party wants something urgently (e.g. a tracking code is being changed, a seasonal ad campaign was suddenly signed)
• This is not to be used for VIPs to push their pet projects; those have to be approved at the prioritization meeting.
  
2. Legacy bugs
1. For bugs that are found in code that has already been released. If these are added to a sprint, then eventually no new work can be done in sprints as all available time will be used for legacy bugs. Therefore, legacy bugs need to be taken care of in parallel to the sprints.
3. Maintenance
• Time needs to be allocated for maintenance of systems without becoming the man focus of the team, similar to the philosophy of legacy bugs.

These 3 types of incidences need to be attended to without affecting the sprint's schedule. With experience, a Project Manager will become adept at predicting the unpredictable and will know how much slack to add into the schedule.

Once a team has agreed to its upcoming sprint, an atmosphere should be created  to ensure that the team can focus on its sprint, and realizes that it is expected to meet its commitments, come what may.

This is easier to enforce if the major players involved are in attendance at the prioritization meeting, and they they each have a say in defining the sprint.

If management are in the habit of interrupting sprints with special demands, then they should also be present at the meeting, so that they can later be confronted with "But you agreed to the scope at the meeting. Please keep this for the next sprint."

Stop starting. Start finishing.

When we started using the Agile development concepts at Answers.com, we started by putting up a Kanban board.


We then created a post-it note for each active project.


Result? The board was not big enough and the concept of Kanban looked overwhelming. How were we supposed to track this many projects?


That's when we took the drastic step of stopping many of the projects we we re working on. We implemented the "Stop starting; Start finishing" philosophy.


Initially it was counter intuitive: We were trying to get more done by doing less?


Yes. That was the game plan - and it worked!


Instead of thrashing between multiple projects, each team was focused on a single project or milestone. More than that: we stopped using each team to its full capacity!


What? You had people do nothing?


No. Never. Worst case scenario, the spare people would take care of things link technical debt; those little annoying things that really should be done but nobody gets around to them.


Most of the time these spare people were taking care of emergencies and other rush jobs that had to be done immediately, if the company was to survive. They could also step in to replace a team member who is absent, or do pair-programming on difficult issues.


What happened? Since the teams were now focused on a single task, and didn't have to spend time deciding which project was more important, and since they were not distracted by "emergencies", they started delivering in record time.


They were now often able to deliver in 2-week increments, including testing. Previously they were delivering in 2-month increments with many weeks of testing and integration issues before the project could actually be delivered.


So the fewer things that were started, the faster they get finished. Throughout goes up, as well as team morale.


It takes while for management to get used to the idea that a pet project is waiting for a slot. But they eventually understand that once that slot is found, their project will be finished in record timing.


But don't they classify their projects as emergencies? In a future post we'll discuss what are emergencies and what gets to jump the queue.


Lesson learned: Do one thing at a time, and do it well. 


- Danny Schoemann

Overtime and All Nighters

Mid-1990s: The Gold Master Disk had to be in Ireland by the following afternoon, if we were to ship on time.


This required us to work all night; I got home in time to see the sunrise, and was expected back at work after lunch.


I was there because each new build required a new setup - and I was Mr. Setups - in those pre-internet days when CDs were a novelty and all programs were installed.

We made it! The Gold Master Disk was shipped, thousands of copies were made, put in boxes with a huge manual, and shipped back to us.

By the time they had arrived, we had discovered some serious bugs and the entire shipment was declared unfit for use. When the company closed down a few years later, we finally threw the entire batch into the dumpster.

That was my first introduction to all-nighters, and the more I lived through them and watched the results of all-nighters and overtime in general, the more I am against them.


After 10 - 12 hours of work, most - if not all - people start being too tired to think straight.


If you cannot think straight then you are a menace on the road and a useless engineer, tester or writer. You - and the project - are better off if you would go get some sleep and restart early in the morning with a clear head.


There will occasionally be that rare emergency that really warrants serious overtime.


When Answers.com - then still gurunet.com - was almost ready to launch, Walt Mossberg informed them - on very short notice - that he was going to write about it them the Wall Street Journal on a specific day. The team did an all nighter to be ready for their premature launch.


But as a general rule, chances are that you are wasting time working too hard. Some advance planning and professional Project Management would be a better idea.


Work smarter, not harder and longer.

- Danny Schoemann

The Magic of Milestones

Project Managers talk a lot about milestones.

What are milestones and what do they do?

Milestones as per the dictionary are:

1. A stone marker set up on a roadside to indicate the distance in miles from a given point.
2. An important event, as in a person's career, the history of a nation, or the advancement of knowledge in a field; a turning point.

Or - closer to our discussion - Milestone or  key activity:

1. (industrial engineering) An activity that possesses major significance. Also known as milestone activity.

It makes sense to break up a project into milestones, each milestone being 2 - 3 weeks long. At each milestone the team will deliver something.

 

This allows the project to have points along the way (milestones) at which to be able to pause and check:

• What have we done so far?
• Is it what we want?
• How long did it take vs. how long we thought it would?
• What's left to do?
• How long will it probably take us?
• How does that compare to our original estimate?

It's a also a good time to take some measurements:

• Is the product still/already fast enough? Small enough? Cheap enough? or any other metric we care about.
• Try getting feedback from internal users, or the QA group or a small test/beta group.

Milestones also give a sense of achievement. We have finally delivered something. Not being able to come up for air for many weeks / months / years can be depressing, or wear down the team.

A milestone is a good time to have a mini celebration, pat each other on the back, do some team building and rejuvenate the team for the next milestone.

Millstones break down the project into smaller pieces making it easier to report progress.

Sync up in 15 minutes: The daily stand-up

The more people involved in a project, the harder it is to keep everybody in sync.

Sending status updates by email sounds like a good idea until you try it. At some point (after about 2 emails) most people stop reading them; they seem so repetitious.

Having a meeting should work, but it is very time consuming, and to be effective everybody needs to be persuaded to arrive on time. In reality many people's minds start wandering during meetings, unless their specific part is being discussed.

What does seem to work is a daily 15 minute stand-up:

• Daily: This way the updates are short and few, allowing people to concentrate.
• 15 minute: This wastes little time and gives people an incentive to arrive on time, else they miss the entire meeting.
• Stand-up: Once seated, people are happy not to move for a while, and meetings can drag on. When standing, people are happy to end the meetings quickly.

Where to do the meeting? We used to do the meetings at the Kanban board which had all the tasks laid out on sticky notes. This way tasks can be moved from the "pending queue" to "in progress" to "ready for testing", "in testing" and "ready to deploy".

What is the point of this meeting?

• Status update: Who is falling behind and maybe needs help
• Either help with the current task; shrink the scope, or add manpower or group thinking
• Or else help with the task queue; hand over some future tasks so that the same person isn't an eternal bottleneck
• Schedule update: When does it look like we may be ready to hit the next milestone
• Milestones can also be redefined in real time if needed
• Attendance: Who will be away in the coming days, who is on sick-leave and may need help with outstanding tasks.
• Implementation feedback: informing the team how something was implemented (in 90 seconds) so that good ideas can be adopted team-wide and bad-ideas can be caught early on.

Invariably issues will arise that will take a while to discuss. After about 60 - 90 seconds, the Project Manager should make a note of the issue and then declare let's take this offline.

If needed, a meeting can be called to further discuss the issue. Otherwise, after the meeting has ended, the relevant people can be asked to stay on and finish discussing the issue. This allows most of the people to return to work, while those interested and/or involved can discuss the issue at leisure.

At the next daily stand-up, the conclusion of the meeting should be announced.

At Answers.com we often had 2 or 3 15-minutes stand-ups scheduled one after the other. This forces them to end on time.

After each meeting, the Project Manager must send around the meeting minutes. I used to reply-to-all to the same email every day, with a few updates.

Sometimes sending the same email with today's changes in a different color is effective.

A chart can be used with a new column for each meeting, with a maximum of 4 or 5 days worth of history in the chart at any time.

Deadline: Friend or foe?

Deadlines are a double-edged sword.

Without deadlines there would be no pressure to get a project finished. Projects without deadlines can continue forever, as people continuously add features and try perfect the product.

More seriously, work tends to fill up all available time. So, if there is no deadline - or a very generous deadline, all the available time will be used up; and the project will still have trouble getting to a finished state.

On the other hand, deadlines create pressure.

• Some people don't work well under pressure, and their work would be better if there was no deadline, or a very far-off deadline.
• Deadlines cause people to take shortcuts, in order to meet the deadline. This could be a a pity, if the deadline is fictitious; it simply means that the project will need a follow-up project to clean up from the mess caused by the deadline.

When working in continuous-release mode, deadlines can be ignored. Whatever is ready by the release will be shipped; whatever is not ready will wait for the next (soon to be) release. However, a Master Schedule with best-case guesses is still a good idea, if nothing else so that you have a list of what needs to be done in which order, and to track how far you are from completing the project.

This concept of projects without a deadline will have the side affect of dividing the team in 2:

1. Those who continue to work fast, and always have their part of the project ready as expected. When they miss a self-imposed deadline, they will try catch up the lost time, or apologize.
2. Those who take advantage of the freedom, and see no reason to speed up.

It's obvious which half of the team you will want to replace, sooner rather than later.

- Danny

Perfection: the enemy of completion

I'm used to have 2 signs hanging on my office wall. One of them says "Perfection is the enemy of completion". (The second sign I'll keep for a future post.)

As much as we all assume we are perfect and can produce bug-free products, reality simply does not allow it.

For example:

• If your product works perfectly on newer browsers, it won't work well on older browsers
• If your product is designed for older browsers, it will look really outdated on all browsers
• If your product runs well on newer versions of windows, it won't work at all on old versions; and vice-versa

But even of you target only a specific subset - e.g. a single version of a single model of a mobile phone - you still can't produce perfect software, unless you are writing a tiny application.

Since nowadays applications are event-driven, you can never tell in what order the user will use the software. They may do things that you never would imagine.

What you can do is have robust error handling, so that it fails gracefully. E.g.: On the web, if you go to an unknown page, you get a 404; you don't break the Internet.

Nicer still is when you customize your 404 page to be friendly.

At some point you have to decide that the system is ready for shipping, even though it's not perfect. It's a Project Manager's job to understand the system well enough so as to help make the call: It's complete even though it's not perfect.

In a future release you can always decide to improve the product to try make it perfect; or you may decide to add more "almost perfect"  additions to it.

- Danny

Is Project Management all about scheduling?

The short answer to "Is Project Management all about scheduling" should be "No".

However, that has a caveat. based on my experience, if a Project Manager insists on keeping the schedule up-to-date, then scheduling will become his full-time job.

As we already mentioned, schedules are always out-of-sync with reality; while you are updating them the reality is changing. As a result, you will spend 100% of your time updating and collecting updates.

In a future post we will discuss EVS (Earned Value System). The most important lesson I learned from using EVS was this. It's irrelevant whether the task is 41% complete or 78% complete. It's either 0% (not started), 20% (started), 80% (ready for testing) or 100% complete, having been blessed by QA.

This saves a lot of useless schedule updates, which are meaningless since nobody really knows how long the task will take, and often the last 20% of the task takes 80% of the time. More about that in a future post.

So, "Is Project Management all about scheduling?"

No! A Project Manager needs to keep track of lots of minor details that people mention by the way.

A Project Manager needs to keep the team focus, and remove distractions, finding other resources (including himself, if needed) to do these.

A Project Manager is responsible for the meticulous coordination of projects from inception through to the finishing touches.

As my sig file at work used to say:

- Danny. Doing. Making it happen, with a smile.

Schedule: Why bother?

Most schedules are outdated before you finished typing them.

• "Remember that 5-day task? I finished it already; took me 45 minutes."
• "About that 1-day task... it's going to take at least 2 weeks, because...."

So why bother making a schedule?

1. It sets Expectations:

• Engineers now know what delivery date management would like. Some - if not all - people work better when they have a target, and they know they are being watched.
• Management has an idea how long it will really take.

2. It creates a Task list:

• By asking all those involved how long their piece will take, they will [hopefully] come up with most of the missing pieces; items you probably never knew needed to be done.
• It also enables the change control process, since items not on the schedule are out of scope.

3. It creates a Baseline:

• This is important if you want to learn for future projects. This way you can measure which team members are better than others at guessing how long something will take to implement.
• This way you can have periodic meetings to see if you are behind or ahead of the schedule. While you probably can't do much about it, it will give you the information you need for status reports.

4. It allows everybody to see Dependencies:

• If one piece is dependent on the other being done, the person who will work on on the 2nd piece can do something else meanwhile.
• If the dependency is basically waiting for the same person to finish one task after the next, then maybe adding more people will speed up the project.
• If one piece is taking up a large chunk of time, then maybe it can be broken into smaller pieces - and worked on by many people - or maybe its scope can be reduced for this release.

On smaller projects it often does not make sense to update the schedule. The schedule is simply used as the Master Plan against which you can track and report.

- Danny Schoemann

Scheduling in the 21st century

Surprise! In the 21st century the art of scheduling - and the joys of creating elaborate Gantt Charts  - is becoming less and less relevant.


Why is this so?


Because  - at least in the software world - projects are being delivered continuously!


As soon as there is something to ship, it can be uploaded to the web, and as improvements are made, they can be tested and shipped as updates.

However, there still are some large projects that need industrial-strength schedules.


The easiest way to schedule a large project, is to find out when the boss wants it delivered. This way at least one person will be happy with the initial schedule. :-)


How long does it take to write new software? The real answer is: "we don't know", since this piece of software has never being written. If it had been, then we wouldn't be writing it again.


Experienced programmers do have an idea how long it will take them; experienced Project Managers will know how to gauge that estimate and how much padding to add to it.


Padding:

• When in doubt, simply double the number and add a week. "Many a true word is spoken in jest" aptly applies in this case.
• As a rule of thumb, (based on years of creating schedules,) I believe that 40% of anybody's time is unavailable. Be it vacation, holidays, parties, meetings, sick leave, miluim (as reserve duty is  called in Israel) and other reasons that prevent people from working on their project.
• The estimate you got always assumes they will be working 100% of the time. Always look at a calendar with all local holidays, check the company vacation calendar and speak to the resource in question.
• Even if there's 100% certainty that none of the above will interfere, you still need to add in 20% for the predictably unpredictable.
• An estimate will never include the following, which need to be added:
• Integration - unless your project is a standalone application implemented by a single person. Every milestone will require at least 1 day of integration, unless somebody can prove otherwise.
• Always get these proofs in writing... this will usually prevent the same person from contradicting you next time.
• Testing
• The testing schedule also needs to be padded, as above.
• The testers will usually need time to learn the system, or the changes to the exciting system.
• Debugging
• Testing almost always uncovers bugs that need to be fixed.
• This will affect the engineer's schedule for the next phase of the project.
• This will require another day of testing, at a minimum.
• Documentation
• If needed, then assume it cannot be completed before the debugging stage.
• Maintenance
• Unless the engineer is new (and you allocate for the learning curve) you will have to add padding for them to maintain all the projects they have ever worked on. We have seen cases when senior engineers get no work done because they have a full-time job maintaining years' worth of legacy projects, and assisting (relative)newcomers to learn all the legacy code.

Now you can try create a schedule, which will be out-of-date before you finish preparing it.

In a future post we will discuss how often to update a schedule.

- Danny