What language?

Someone told me once: "If it ain't programmed in Java following the Extreme Programming principles, we don't want to buy the software." Arguing about why he put this statement so firmly, the person orated for an hour on the great advantages Java has in respect to more traditional programming languages. And in combination with principles from Extreme Programming the resulting software would be perfect. He was talking about policies put onto a system he was going to buy…

Do you care in what language your word processor is written? Delphi, Smalltalk, C++ or Miranda? Probably you don't. Why should you care then when it's a specific information system you buy? You should pay attention to this aspect, that's for sure. But, not because the syntax is so neat, and certainly not because some external bureau, (or a Guru on a seminar) has yelled that Java is the way to go.

So, why should you consider these aspects? For the use of the software itself you don't care what is under the hood; if it runs, it runs. But for the continuation of the system in the future it is a factor to consider. If an obscure programming language is used, it may be difficult in the future to find good programmers skilled in this particular language. This is definitely a risk for the quality of the software in the long run; as you know, people come and people go, also programmers. As for programming principles, let everyone program in on the way that works for them best. Just look for principles; are they available and used? The companies only stake is to have no surprises, in the quality of the software and in the process of constructing the software.

Like before, with the stakes you can do something. They're valid business arguments and leave some room to operate. Still wonder what the stakes were of the guy that told me "if it ain't programmed…"? I guess he has programmers employed, who want to program using way cool techniques they have learned at a seminar. But that's just my guess.

Are you thin?

Software architectural discussion are always the best. You draw four boxes with several arrows between them, and state that all systems should comply with this architectural design. "All systems should use a 3-tier architecture". I will not explain what it is (if you want to know, just look it up), only that in the segment where I operate there are very few systems that follow this architecture (at the moment I write this book). So, you have to build it yourself?

Searching for the stakes took my quite some time. Talking to toga's, dissecting there arguments, turning them over, looking up close, looking from far with my eyes almost shut… The effect of this policy is that on workstations less software is installed then traditional, the so called thin-clients, which seems to be easier to maintain. Second effect seems to be less network traffic, which allows the purchase of less bandwidth and saving money.

Ease of maintenance and saving money on bandwidth are in the end the original stakes of the company. Die hard technicians might now complain: "that's not the real power of 3-tier". Perhaps they're right. The point is, it doesn't matter. The requirement is formulated, correct or incorrect, but it's the stake that's important. So before redesigning your system you can consider cheaper alternatives for saving bandwidth and ease of maintenance. You go against the policies. But presenting the alternative requirements in such a fashion they keep supporting the stakes, is most of the time a winner. It is at least worth a discussion.

Respecting the unborn child

When buying a house, some of my friends want extra room for the kids, they might get, someday, maybe. They try to anticipate the coming of the unborn, better yet, the unconceived child. While purchasing a house this kind of anticipation is easy, one child is one room extra. You do the calculations.

Consider the following situation: the current system is in state of collapse, there is a technical necessity to replace the software. That's the cause and goal of a little happy project. Parallel to it are some larger projects, that are "strategic", and therefor have larger visibility and in perception a higher priority. Policy is you have to consider the "strategic" projects and keep in line with them. As you know "strategic" means large time frames, vague requirements, and big changes, sorry, reorientation. Try to keep in line with stuff that can't give you a date, or specific requirements, let alone, the quantified benefits. It's like saying to a professional athlete to keep in the same pace of this senior citizen with a Zimmer-frame. What do you mean, slowing down?

Again, the story becomes annoying, you should focus on the cause and goal of "strategic" projects, they can be considered as stakes. Try to create the situation where you can align with the projects when they have things clear. Try to avoid the situations where you make it impossible to align anyway. Don't say, forget it; "strategic" means a lot of higher people are watching, and giving the finger to higher management is always a bad career move.

Why does the chicken cross the road? To get to the other side. Now a little more difficult… Why do the English drive at the left side of the road? Personally I have no idea where this "left side" comes from, and, personally, I don't care. These Islanders just made an agreement once, and stuck to it, just to avoid running into each other.

Why does the software I want to buy for the company has to comply with J2EE standards, ISO standards, etc? First of all, I don't know what they mean, and second… why? If you go out eating, you don't care if they use a Siemens or a Philips microwave to nuke the food. However, you do want to keep your stomach at ease.

At companies, large and small, there will be some statements made about what your software should look like, and to which specifics it must comply. The Policies. They're annoying, they're anonymous and they're here to stay. "All information systems should have a 3-tier architecture." This is what a typical policy looks like. In case you will stumble across one, you will recognize the beast. It actually sounds like a requirement, doesn't it? No wonder, it actually is.

Policies are requirements too

Policies can be viewed as requirements made by the company itself. Following the argument of this book, the company should have stakes. I know, I argued in chapter "Intake" that only individuals have stakes, as it is a person who has fears and wishes. At the end of it all, I'm not taking that back. With company stakes it's only difficult to pinpoint exactly its original owner. Can be the board of directors, your boss or the "Policy Department" (those guys walking in toga's and stating the obvious as Nobel prize winning stuff). It also may be stakes that are inherent to operating a company, like "making a profit", so "we should earn more than we spend."

Back to the original question, why does the software I want to buy (or perhaps make) have to comply with certain policies? For the same reason it has to satisfy the stakes of the stakeholders; to make everyone a winner (including the company), so you have a happy and successful project. If the policies are the requirements, what are the stakes and can you change the policies? Now, that's worth some thinking.

Consider the situation where a toga from the Policy Department descends from his ivory tower to the mud of the software project. He has with him a paper role which content he shares with you in a loud voice: "Hear, fools, hear. Thou shall comply to these standards: J2EE, ISO and OSI. Thou shall use these techniques: UML, DPL and JBF." The crowd goes wild, sets fire to his paper role and kicks him back up into the tower. However, his glass tower is next to the quarters of Zeus, the Almighty Boss, who hears the whining of the toga and sends his thunder upon your little project. Thou shall comply.

You can ignore it, but you will get trampled upon. You can fully comply, and you have stuff that no one wants, no one with money to pay for it at least. So, you have to dive into the stakes that are behind the policies. And most of the time they are good ones, things that really benefit your project, and your company and, in the end, you.

Thou shall use The Big O

What are the stakes? I cannot be specific, there can be a lot of things. But perhaps some examples I experienced may help you on your way. "Every database should be Oracle." (or just pick a vendor you like). When buying a system, it can be simple. "Does it run Oracle? No? Sorry, we don't want it." But, normally you buy functionality and not technology. You buy a system for what it can do, and not because the bits and bytes are flipped in a certain way. For normal use, you buy a car to get you from point A to point B, and not because it has yellow spark plugs. You can ask the supplier to port its system to the desired database vendor, but you get a special version of the system (which is a nightmare in maintenance) and likely the supplier has limited knowledge about this particular database.

The stake here has to do with sharing database administrators among several systems. The company benefits from efficient use of employees. Especially concerning specialized people. Database administrators (DBAs) are a good example. Having more similar systems that these people can maintain, will make the costs of maintenance drop. Using a more mainstream database like Oracle, makes it also easier to get some outside people from the market to do the tasks when your own employees are overloaded or not available.

In this case it is not that the database should be Oracle, but that we should make efficient use of the current DBAs, and should have no problem finding outside people to handle the system. Now, that's a company stake!

Every zoo tries to get a very nice and balanced variety of animals to present to its visitors. Species are grouped together, in a coherent way, and if you follow the tour that's laid out for you, you flow through nature in a natural way. But there is always this small pavilion at the back of the wall, in the shadows of the trees, where they keep the ugly and weird animals. They must be in the zoo for completeness, but they never fit anywhere in the normal tour. If you insert them anywhere, they interrupt the flow.

Links of Interest
Lessons From The Pond For The Project Workforce

My last section is the pavilion in the back of the course. It tells two stories that have to be told, but only fit at the end of the text, on their own. They tell the stories of doing the projects within your organisation. Your organisation is not a person, it's a collection of people, but even this non-human institute has stakes and requirements. They are called policies. The first story is about handling policies issued on what software you may make or buy.

The second member of the pavilion is the introduction of a project style of working within your organisation. It's nice if in the end you know as a project manager what to do, but if more people within your organisation are in tune with how software projects should be done, it would increase your effectiveness significantly. However, traditionally this is done from the top down, as a directive from above. And this is the most fundamental mistake you can make.

In the previous section we talked about how to start talking about the risks. You take a certain aspect and think about it in terms of what you don't know or what might go different then expected. Even better, you do this exercise with some colleagues in a meeting. For every risk that you might come up, you have to specify the following items:

· Risk; A description of the actual risk. Example: Uncertainty availability programming resources.

· Impact (or consequence); The impact on the project (process or product) if the risk occurs. Example: Delay in construction interfaces.

· Possibility; The possibility that the risk occurs (use e.g. high/medium/low). Example: Medium

· Action; The action that can/will be taken to avoid the risk from happening or reduce the chance for it, or reduce the impact. Example: Get planning clear. Investigate possibility external programmers.

· Cost; What is the cost if the risk occurs (time and money). Example: Delay 3 weeks.

You have to review the list that is generated in this way periodically (once a week). If the list is too large to give all the risks your attention, you have to create some priorities. A nice way is to create every time a top ten of the most urgent risks, so you will be sure you focus on the more important ones.

There are a lot more things to say about the subject of risk management. But first of all it's a state of mind. And with the few things shown in the section, you have a good starting point to reach the state. Remember, risk is not a bad thing, and if you come up with an action to resolve it, execute it… don't just talk the talk, but walk the risk management.

What you don't know, can't hurt you… You sure, right… not. When you are hooked on cigarettes, you smoke like a maniac, chances are you will claim you aren't addicted. Even if you can't stop, there's always this "if I really want, I can stop right away." You are in denial. You know you have a problem, but you're mentally not ready to accept it. In software projects you also have these kind of "denial" things.

You know problems can occur, but you just ignore them hoping they will blow over, will not happen anyway, you don't want to rock the boat, cross that bridge when we come to it… ("… if there is a problem, we get over it…", lyrics of some old 80ties disco tune).

So, basically, there are things that you know you don't know around software projects. If you ignore them that's bad, but at least you know. And yep, there are more problematic things, the stuff you are not aware that you don't know them. They will sneak upon you, and you'll never know what hit you. It's very difficult to prepare yourself for the REALLY unknown.

If you have done this software risk management thing for years, you develop some nose for it. You have feelings ("FEELINGS, hohohoho, FEELINGS… lalala"), you have some gut stuff, etc. But how do you start this ability to identify risks? Or, how to bootstrap your gutt.

Develop risk checklists for software risk management

The answer my friend is … checklists. Start creating lists of points that you want to review for risks. As you do this more often, your risk management checklist will grow, you can put all your experiences in it, in order to avoid having the problem in the future. But how to get started?

First of all, you are not alone. This is not a unique thing you are doing. So, of course, there are standard checklist you can start from. The Software Engineering Institute provides a very nice starting point. The SEI risk taxonomy is a structured risk checklist that organises software development risks into a certain framework. But, with all the work you have done in the previous sections, you also come a long way. We could name it "Stakeholders Risk Taxonomy", or, more appropriately "the bloody list." I created it by writing down 30 minutes some aspects I covered in the previous chapters. It is not intended to be complete, it is merely intended as an example on how you can deduct checklist from this book.

Stakeholders

* Have you identified all stakeholders?

* Have you identified from all groups the leader or spokesman?

* Have you ever met the stakeholders?

* Do you have information on the background of the stakeholders (history)?

Stakes

Fears

* Do you know what the fears are generally for the type of stakeholders you have (e.g. programmers)?

* Do you know what the fears are of the stakeholders per group?

* Do you know what the fears are for each individual?

* Do you know how this project affects the fears of the stakeholders?

Wishes

* Do you know what the wishes are generally for the type of stakeholders you have (e.g. programmers)?

* Do you know what the wishes are of the stakeholders per group?

* Do you know what the wishes are for each individual?

* Do you know how this project affects the wishes of the stakeholders?

Requirements

Product

* Are the cause and goal of the project clear to you?

* Is the project scope identified and does it include what you can change, what you must change, and what you can't change?

Process

* Are the constraints identified (money, time, people)?

* Do you have any idea how much room there is to negotiate these constraints?

* If there are already estimations, do you know how much you can trust them?

* Is the project strategy clear and easy?

* Is the project organisation identified? Does every member have added value to the project?

Project management

* Are you able to negotiate?

* Are you able to think in win-win situations?

* Are you risk averse?

* Do you include your own stakes into the process?

* Are you able to give the project back in case it smells like a trap?

Feedback

* Is everyone aware for the need and use of giving feedback?

* Have you any idea how to provide feedback?

* Do you really understand the techniques you want to use?

* Did you schedule (time, money, people) activities to provide the feedback?

Dealing With The Unknown

You have come a long way, all the way up to this chapter. I have discussed expectations, estimations and anticipations withing a project. I tried to make it sound as good as possible, but let's face it, it's all vague stuff. You have to think about how someone else thinks, and base your complete approach on that assessment. We handled requirements, and stated that it's best to assume that they are wrong and will change anyway. It, it's like flipping a coin or laying cards.

Software project management cannot be performed without a good practice to handle all these unknown parameters. A project manager has to be able to live with uncertainties, and have a good way to structure his approach to handle them. The first is a personal aspect, which you have to do all by yourself. The latter is where "project risk management" comes in…

"Project risk management focuses the project manager's attention on those portions of the project most likely to cause trouble and to compromise participants' win conditions." [Boehm,1989 ]

So, in other words, it's a set of actions which helps the project manager structure his approach on dealing with the unknown or the "things not sure".

"… we define risk as the possibility of loss. We obtain an instance of risk by specifying values for the risk attributes of probability (the possibility) and consequence (the loss). Probability is the likelihood that the consequence will occur. Consequence is the effect of an unsatisfactory outcome." (Hall, 1998)

So, the idea is to specify explicitly the items that you are not sure about and define what will happen if what is expected (or assumed) is not true.

If you are not sure about the estimate ending of a certain task, you can define the risk for this situation as follows: delay of the actual end of the activity * very likely to happen. What the consequences and advantages are of this approach, is the subject of this section.

Risk is not a bad thing

The problem with risk management is the negative image of the word "risk". Of course, unless there is a potential for loss, there is no risk. The loss can be either a bad outcome or a lost opportunity. The tendency of most stakeholders is to jump very stressfully at the statement "this is a risk". Therefore most of the time it's not very easy to discuss about risks, because that's always a conversation about problems. It's very important the risk is not perceived as a bad thing, but as a positive attitude to make sure everyone will become a winner in the end.

Remember, risk management helps you being aware of the goals you have to achieve, and what can happen if you don't satisfy the goals. It supports you in making the right choices!

So, risk is not a bad thing! Say it loud! Spread the word!

Related links

Numbers Are Useless To The Novice

Human Failure Modes

Now you can create nice spreadsheets with indices, draw tree structures that resemble your tasks, and what does this bring you? First of all, it brings you acceptance as a Project Manager. Project Managers are supposed to create such things. Many customers are not happy when their Project Manager doesn't show up with an Incredible Gantt Chart (preferably printed on A3, double sided).

Financial people want to see the numbers. What does it cost me in the end? They want to know as soon as possible. You can hit them now with the EAC. And, of course, the techniques are ok, they help you structure your mind, your information overload, your life.

Project progress reporting is only a nice job if you take care the expectations of the stakeholders are in line with the current situation. There is no such thing as good news or bad news. If you run over budget, that's bad news. If you stay under budget, that's for most companies also bad news; if you are a supplier and your consultants will do the job in less time then expected, you make less profit then expected, hence pissed stakeholders.

Extra pot of gold

Again, like the entire message of this book, take care of the stakes. It's not just the numbers, it's the consequence of what they represent that causes negative reactions of stakeholders.

With budgets the guy or gal responsible always has to defend changes to a higher level. Consider a system that will be build for a certain business unit A. Parts of the system build for them, will be used later by five other business units. At the start of the project, business unit A has a budget for the complete system. Of course, they run out of budget. Supplier and customer are rolling over the floor: "your fault", "no, it your fault", etc. No one wants to defend the overrun to the higher level in the company.

Suddenly, some one suggests to take the costs for the parts of the system that will be used by other business units also, out of the original budget, and create an additional "pot of gold" for it. After all, it's not fair that this one BU pays all the costs on it's own. Applause. This is something they can defend to higher level. Their budget remains unchanged (with no overrun) and a new budget is created. The numbers remain the same, the fact that more money will be spend than originally thought remains unchanged, but this is fair and no one looses face. Yep, I was there. Was not my suggestion, sadly.

Extra tasks

Imagine, in your project schedule you have planned "testing". Some stakeholders are highly committed to the deadlines for your schedule (they promised probably some one else). Your system will not be ready on this time for testing, at least not the entire system. You can propose to keep the deadline for "testing", and add an additional task after it called "integral testing" or "test it again, Sam". The stakeholders can remain their word (they just said "testing would be finished") and you have your extra time.

I am not claiming this works all the time. I'm just showing that you should be creative in the negotiation on budget and schedule.

You will need to talk with financial guys, so I spend a section on higher mathematics… Remember Dick? He was part of the budget to program some application: he was supposed to spend 5 days, with a total cost of $5000.

Suppose we schedule Dick to start on Monday and is planned to finish after five days on Friday. If you want to monitor the cost for Dicks' endeavor you just need to monitor the value of the budget: $5000, which is what is originally estimated. By the way, a complete budget, which is agreed upon by the customer is called a baseline. The budget might change due to discussions and new insight, however, the baseline can only chance after a signature of the customer. On Wednesday, Dick spend 3 days working on the stupid thing, so at that time the cost in reality are $1000 * 3 = $3000. This is the actual project cost.

Dicks' manager could yell now: "the job is 60% completed!" However, the correct phrase should be "we have used now 60% of what we originally thought (budget)". Looking at the bits Dick produced, reveals that he has only done 25% of the application. So, actually the cost should be 25% of $5000 (total budget of Dick) = $1250. This value is called in "advanced project management lingo" the earned value.

What is the progress? Well, 25% of the total work to be done. Used 60% of the budget and estimated time. The question that has to be answered is "how much will it cost in the end?", "when is it actually finished?" Dick will say, he will work harder, he will make up in time. He probably will. But, not so much that the difference between budget and actual project cost will vanish.

Enter the "Estimate at Completion" (EAC). This is a forecast of total project costs based upon how the project is currently doing, the project performance. It's something you have to calculate. Preferably with a computer. EAC is calculated by taking the total budget and divided by a performance factor (the cost performance index, which is Earned value / Actual cost ). This assumes that the percentage the project has overrun today is going to be the same percentage that it overruns at completion.

So, for Dick on this Wednesday, the following overview holds: actual project cost $3000; total budget $5000; earned value $1250; cost performance index 0.417.

Which brings us to an EAC of: $5000 / 0.417 = $11,990.41.

Dick's in trouble.

"This isn't a project plan, it's wallpaper for the Tardis you're going to need to meet these ^&*&%*& timescales."

"Why is it a programmer has these success stories on how he constructed in his free time the most incredible foo-compiler within 2 days? Without bugs? Why is it that the same programmer cannot finish a simple dialog for a payroll system within the agreed period? A period he himself indicated (which by the way he largely exaggerated)? If it isn't going to happen any way, why does a project manager bother planning programmers?"

Ok, the previous paragraph is meant in a provocative manner. But being a software project manager these questions cross your mind. And off course, there's another view on the subject, that of the programmer…

"Why do I have the following discussion over and over with the project manager: 'I told you it would take 3 weeks - why did you cut it to 2 weeks, just because it met the quarter reporting deadline'. Why do I have to tell you that your $%^&^ plan bears so little relation to the Babylonian calendar that the rest of the world uses that you must be a ^%%&* Maya."

I know why I need a planning. It is a useful tool to communicate the tasks, time scales and dependencies within a project. It's a way to indicate the agreements with several parties on when what is ready. But why should programmers be bothered with a planning? What are the effects on them handing over a Gantt chart? Is it the right way to communicate any way? What does a programmer want from a planning?

So, I posted on an internet discussion forum this simple question: "Can you tell me why you (as a programmer) need a planning?" This section reflects some of the answers and, of course, strongly my personal view on the matter.

Planning vs. schedule

I will use the term planning and schedule interchangeably in this section. Actually a planning can be a larger document with backgrounds, etceteras, and a schedule (tasks, person, time). However, large documents are never read, and everyone just goes straight for the schedule. So, in most cases just the schedule is provided. That's why we can use the terms, for the sake of this section, for the same item.

Agreement

When I order some furniture in Holland, the guys who will deliver the stuff at my home will send me a letter indicating which day they will come to my doorstep. The day for them starts at 8am and ends at 10pm. So, I take a day off and wait. Sit and wait.

Sit and wait is not my favorite waste of time. Especially on the job (I'm a fanatic, what can I say). For the projects I run, I will have some kind of planning, so I know when I can get my stuff to bring to the next guy. This next guy is also glad that I can tell him exactly when he gets the stuff he needs to do his thing. All in all, from my planning I can tell a lot of stories.

My storyboard in this respect might be a Gantt chart. I can send this chart to a fellow project manager, and he will immediately now what I mean. I use the chart also to put in how long and when a certain programmer performs a specific task. I do this to put our mutual agreement in writing. "How long will it take and when will it be ready?" "Well, it takes 1 week and I start on Monday." The Gantt will be used to let the programmer know I agree on what we agreed and let the rest of the world in on out little secret.

So, that's why I, a software project manager, send the programmer the planning in the first place. Why do I need a written agreement, and can't I be satisfied with just a telephone call? I wasn't even aware of the question, let alone the answer… But someone posted on an internet discussion forum a fairly good answer…

You need a schedule for the programmer, otherwise he will never do the job you ask of him. Remember the first paragraph with the foo-compiler and the payroll system? This specific programmer would rather be writing a compiler then creating a non-challenging dull dialog for the payroll system. So, if you let him schedule his own stuff (or no planning at all), he will probably do the things he really likes first, internetting, chatting or taking the kids to the zoo.

If you would approach this pessimistically, issuing a schedule is the only way to provide the project manager with some power; non-delivery of a product is something that can be proven easily, and is therefor a perfect form of surveillance on the programmer. And this form of monitoring is needed, otherwise the programmer just slacks off.

I'm not completely happy with this form of reasoning, it's to darn pessimistic. But, if we are looking for a short statement on reality, this one is fairly close to it. I want to communicate to the programmer our agreement. This is still the case. I'm only wondering if providing a Gantt chart is such a smart move. I'm curious how I will respond if he answers me with something in UML or Bachus/Naur form.

What this thing called 'planning'?

The software project manager walks into the room. Very proud, handing over his new, fresh Gantt chart. It's shiny. The programmer looks at it. Holds it up, against the light… The project manager wonders what the programmer is thinking.

"How do I read this? What is this?" The more experienced programmer goes straight to the second thought: "What happened to my numbers? I told him it would take 3 months, why did he slash it to 1?" Actually, this may not be a surprise if you think of the planning as a written agreement. The programmer first looks if it might have changed, by one party. The one who writes the document, has the power to change the text. And sadly, the 'text' of a schedule is very limited; there is no explanation on why things are what they are, why the estimate was changed. Decreasing someone's estimates of his own tasks, is a bad suggestion in the first place.

The handing over of the planning is the first form of feedback from the project manager on what he actually did with the estimates the programmer provided him earlier. If they're the same, the manager gained some credibility, if not, he's lost forever.

Focus on the past, not the future

But, this large chart, does it provide some use for the programmer, besides just the line with his own tasks? Yes it does… it can provide insight in the quality of preparations for his task. The tasks after him or not of much interest, but the past, what happened before is key.

Having the right preparations is essential. Without them "… the result is that when I have to do some work, I loose a lot of time getting the preparations done (that have been 'forgotten' to take place), talking to people that I need the results NOW, doing things myself because the right person has other priorities, etc. And the result of this is that other people come to me wanting results NOW for work I didn't know I had to do…", as one programmer puts it.

So what?

I hoped that I could say "we can throw the planning out of the Tardis, we don't need this thing". Sadly, we do. It's a way to communicate an agreement. However, if this way should be plotted on A1 with only a Gantt chart? I don't think so. I hate these charts anyway.

If you take all you tasks from the WBS, and your estimates how long they will take and, when they could start and finish, you have the ammunition to create one of the icons of project management: The Gantt Chart. It is a good way to visualize to information you have before you. And, because it's considered an Icon, using it in your communication will set some stakeholders at ease.

Related link
Burn-Down Chart Instead of Gantt
The Death Of Gantt Charts?
Reality Refuses To Follow Your Plan

Basically, a Gantt chart is an overview of tasks. You put weeks, days or months at one side, and the tasks at the other. You draw fat lines to indicate the period the task will be performed.

Put next to the task the name of the person who will do the job, and you come a long way in creating your Gantt chart.

Making A Gantt Chart With Excel (video)

PERT; almost as good as Gantt charts

If Sesame street has Bert and Ernie, Project Management has PERT and Gantt charts… PERT is a notation technique, which has a lot of fun features I will not discuss. The good thing however on creating a PERT chart is that you have to think about the relations between tasks. Can task X start before task Y? Do they have to end together? Must they start at the same time? etc. If you think in this way about your tasks you can create graphs like shown below.

Before you can pour your coffee, you have to get up. Before you can get dressed, you have to be up. You don't have to be dressed to pour the coffee. However, you have to be dressed and had your coffee before you can leave for the office.

Suppose "Pouring coffee" takes you 5 minutes, and "Getting dressed" 15 minutes. Suppose your wife pours your coffee. In that case the time it will take you to get up and leave home is the total time for "Getting up" + "Getting dressed" + "Going out". Say, that is 30 minutes.

As long as your wife stays under the 15 minutes, you have no delay. Only if she decides to make you an espresso, you are late. You see why? This is very useful information. Not for the example I used, but for the project you have to take on. It shows you who has to wait for who, and stuff like that. It shows that a delay of one task, does not automatically mean a delay of the entire project. All the tasks that have this property however, are called the "Critical Path". These activities have to be done sequentially, will take the longest in that time frame, and a delay in one of the tasks within the critical path, will cause a delay in the entire project.

Related link
Burn-Down Chart Instead of Gantt