An approach to planning

Planning a project involves identifying the activities required to deliver the project and the inter-dependencies between those activities.  These activities and the dependencies are then modeled onto a network diagram.

Task duration estimates are often padded, as a matter of good practice, but also as a matter of covering one's behind.  Things often don't go according to plan and one has to allow for that.  If I estimate that task A will take 10 days, and I say it will take 10 days, and then something goes wrong, then not only do I look bad, I might also I end up delaying the next task which was set to begin 10 days later.  So the common practice is to be generous with our estimates and pad them for contingencies.  Such padding implicitly addresses the risks faced.  

There is another approach that integrates project schedules with risk management, and at the same time highlights the possible sources of these risks.

One way to bring this planning to a different level is to first make a realistic and optimistic estimate of how long each task will take.  Let's say if a task will take 7 days if no problems occur, then we start with 7. We do the same for each task. Then we study the task and its dependencies and try to understand what could go wrong that can cause its accomplishment to exceed 7 days.  Then we try to address those things that can go wrong.

Let's say the person executing the task will normally take 7 days to accomplish the task, but has other stuff on their plate, so may take more that 7 days to complete the task.  Why?  Because their time and attention could be diverted to the other tasks.  If we don't highlight this reason then we can't manage it.  Suppose we identified that this person really has other stuff on his plate, then we can take steps.  We can schedule his task to be done after he has finished his other stuff, or we can arrange things so that he suspends work on other stuff, or we can just accept things as they are and simply pad the number of days.  At the very least, we have identified a possible cause of problems.  

There could be other factors to consider: this person could get sick during that time, their machine might break down, they could misunderstand the specifications,  or what's required of them and then we will need to redo things, and so on.

By thinking through the possible reasons for exceeding the optimistic estimate, we begin to identify possible causes of delays and we begin to be able to plan for those causes: try to minimize their chances of occurring, minimize the impact if they occur,etc.

***

Tip of the Day - Estimating

When scheduling any task, especially a time-consuming task, it is always prudent to assume the task will take longer than you expect.  

Things happen.  

Therefore, add an allowance as a contingency.

This is not padding schedules for the purpose of billing higher.  Neither is it about covering your behind and ensuring you deliver before the target date.

It is simply common prudence.

If you believe a task will take 3 days and you promise to deliver it in 3 days, whoever is depending on your task may decide to commit himself to starting their task 3 days later, on the assumption that you will have delivered by that time.

If you fail to deliver as scheduled, then he will probably fail to deliver his task as well.  This chain could go on through to several persons.

Not adding a contingency to your estimate is not merely being gung-ho, it's plain irresponsible.

In addition to adding a contingency to your estimate, however, you must also be prepared to work on the next task if the current task gets completed sooner than scheduled.

Delivering on Scope

Many writers on project management tell us that project management is about delivering the project on time and on budget, with a special emphasis that project management is about the 3 constraints of quality, cost, and time.

Turner writes that project management is about managing the scope and the organization, and that quality, cost, and time are just constraints.  Consider that the reason for the project is the work to be done (in order to reap the benefits of the project). 

Without the work, there is nothing.  Next, consider that the project organization is what does the work.  Without them, there is nothing.  The other three features: quality, cost, and time are not the purpose of the project. They are simply constraints. 

Handbook of Project-based Management

Succeeding by not failing

We keep on building systems that experience failure mainly because we don't learn from our previous failures.  In fact, if only we made a formal effort to study the cause of previous failures, the 'vast majority' of failures would disappear.  This seems to be the thesis of a  book on system failures from Joyce Fortune and Geoff Peters.

The phrase 'system failure' normally brings up the usual suspect of 'computer/information system failure' , and that's not surprising. Information Systems chalk up more than their fair share of failures, or at least the failures that are interesting enough to make the news. One of the reasons is that these systems tend to have so much failure is that they are so embedded in organizational life that there are so many points of interaction and therefore so many points at which failure can occur.

Information Systems are also now so entwined in our social and cultural life that we experience failures almost every day, from a dropped internet connection, to a stolen credit card number.

 

While failures will always happen, a lot less of them would happen if only organizations made proper, formal reviews of what caused previous failures, and then apply the lessons learned, argues Fortune and Peters.   To aid in this noble aim, they have devised an approach called the Systems Failure Approach, an approach solidly grounded in the principles of systems thinking.  SFA lets its user extract failure events from the real world, construct a systems model of the failure using systems techniques and, from the understanding gained come up with a lesson that can be applied back to the real world.

On Agile...

You've heard said it before: in order to learn one must have an open mind.

I think sometimes the opposite is better. Keep a closed mind. Let the new idea try to make its way in with difficulty. Let it argue itself in with facts. Let it convince you of its correctness. Once convinced, make it your own. If the idea has enough merit, it can make its way in.

I've been trying to like the Agile methods, but for reasons I still cannot pin down, I am still pessimistic about these approaches. There is no doubt they work. Sometimes. But that's not a criticism. Nothing works everywhere. Agile's more moderate proponents have never suggested that is applicable everywhere.

I should clarify that I am pessimistic mainly about the XP approach, since that is the methodology I am most familiar with among the agile methodologies. I am still agnostic about the rest.

These methodologies have been developed because of the unworkability of the one-pass waterfall approach. In an ideal world, where people do not make mistakes, the one-pass waterfall is the simplest and most efficient approach to developing software: complete the requirements in one phase, then complete the design, then complete the programming, then complete the testing, and finally, complete the acceptance, and we're done.

But since we're not mistake-proof, the waterfall is simply impossible as an approach, and no one in their right mind will attempt to develop software using this model. Except in the business world, of course.

Here's one of my issues. No one has been complaining that the programming phase of a waterfall approach comes out with a program that does not match the design documents. No one has been complaining that the design documents do not match the specified requirements. In other words, the problem is not with the design phase and it is not with the programming phase. The problem is, and always have been, that the specified requirements do not match the actual requirements.

If that is true, then it is the domain of requirements analysis that is at fault. They come up with the faulty requirements. The domain of software design and programming is just fine -- give us the correct requirements and we'll give you the correct software.

An approach that tries to fix the system development problem by fixing the software design and development phases rather than the requirements phase is looking under the wrong lamppost. And I think Agile is doing just that.

Be that as it may, I'm currently reading Robert Martin's Agile Software Development and have more to say on the topic.

Is Managing a Project Like Conducting an Orchestra?

Managing a project is so often compared to conducting an orchestra the comparison is almost a cliche. It seems to me that the comparison is rather off.

An orchestra has had time to rehearse and practice over and over exactly what they are supposed to do. Indeed, they must refine their work until it is flawless. A project team hasn't got that luxury.  It has only one pass at executing the project. 

An orchestra will never be asked to work faster or redo a task. There is no such thing as crashing the music. Project teams have deadlines to meet and often need to redo work and work faster than normal.  An orchestra performance is an operation. It is perhaps the smoothest of operations.  There is no change of plans.  The audience's (stakeholders) mood will not change what the orchestra will play or how they play it.

There is a slight similarity between conducting an orchestra and managing a project. The similarity lies in the fact that both the conductor and the project manager do not make the actual product. They simply orchestrate the work of those who produce.

But then again, why pick on a conductor as the focus of an analogy? Every orchestra presentation has an actual project manager orchestrating it, scheduling the rehearsals, picking the team, selecting alternate members.

And that person is not the conductor.

Who? What? When? Where? Why? How? How much? Say what?

How do you know if you are still in control of a project?

One way is to ensure you know the answer to the following:

1. Who are the stakeholders in the project?
2. What are their interests?
3. What is the purpose of the project?
4. How much is the budget for this project?
5. How much is this project going to take?
6. How long will the project take?
7. What is the project schedule?
8. When is it to be completed?
9. What is the project plan?

RISK AND OPPORTUNITY

Are risks and opportunities completely different notions or they simply different faces of the same coin? Can you capitalize on a potential risk beside just avoiding the eventuation of that risk? For example, if there's a risk that your top programmer will leave for another job, and he doesn't, therefore the risk doesn't eventuate. But apart from heaving a sigh of relief, is there an opportunity there that you could take advantage of?

Suppose in your project you are expecting a lot of active opposition from environmentalist groups, and therefore allocated an extra $10,000 for the purpose of public relations and legal expenses. But for some reason, the expected opposition did not materialise and you find yourself with extra project funds and the *opportunity* to use those funds to accelerate the project. In this example: - the risk did not eventuate, and opened up an opportunity - the opportunity was there only because you planned for the risk. - you have the basic option of acting as if the risk did not materialise (business as usual), or the more advanced option of seizing the opportunity that opened up and turning it into something beneficial.

Things to Ensure When Running a Project

I'm compiling a list of things to ensure while running a project. The list will be relevant to me. Yours may be different. A complete list will be infinitely long.

This list will be updated as often as I recognize a need to do so.  Currently, it stands as:

1. Make sure you have a clear delineation of the project scope.
2. Make sure you have a clear and complete list of stakeholders and their expectations of the project deliverables and execution.
3. Make sure the project team is clear on the project plan.
4. Corollary to 3, have a project plan.
5. Always have a valid, real, working schedule and stick to the schedule for as long as the schedule is valid. Update the schedule when needed.
6. Have frequent completions and starts (ie, have milestones). This is intended to instill in the team the plan for the next segment of the project.

ON POLITICS ( AND NERDS )

Skill in organizational politics is a function of social skills. The more you have of one, the more you have of the other. Computer nerds are reputed to have a distaste for organizational politics. The word 'nerd' is also often used as if the word itself meant 'someone who lacks social skills'.

It takes, however, an exceptionally analytical and logical mind to become a good programmer. In other words, you have to be rather smart to be a good programmer. So how come that smartness seem to flounder in the face of organizational politics?

Some may posit that the smartness that nerds possess is of a different sort from the smartness required to engage in politics. I disagree. I'm more convinced that their smartness is just not focused on politics.

Nerds simply detest politics. Such an attitude comes out of the pureness of heart. They see politics as an unnecessary evil played by people who need to cover up for their incompetence, or people who see it as a tool to feed their greed. One of the early definitions of politics that roamed the internet was a play on the word itself tself ("poli" - many, "tics" - blood sucking parasites).

Besides the attitude toward politics, nerds are also unprepared to manage things that fight back. They deal extremely well with computers and software, which respond with a deterministic response to stimulus (IOW, they act the same way each time). Politics is about managing people. And people are deterministically unpredictable. The same request to the same person will receive a different response each time. People tend to not want to be managed and tend to want to manage. The nerd is afraid that the engaged person may attempt a coup and end up managing the nerd. Such do not happen in a nerd cum machine interaction.

The pervasive view that politics is only for the incompetent is unfortunate because it gives the viewer an unnecessary disability.

Politics is a part of organizational life. It is an essential part which cannot be removed. Anytime two or more people get together, there is going to be politics. Even if these two people happen to be the most considerate of sweethearts so madly in love with each other. She will do what she needs to do to make sure his eyes do not flit to another. In other words, she will attempt to control his behaviour. She will attempt to manage.

Politics is so pervasive that it is just unavoidable. It's like air. No matter where you sit in the totem pole you are within its reach. The lowliest messenger has to conform to politics (send the messages to the evil bitchlady on the third floor first). If you're not in the totem pole, you are not in any organization. You are unemployed.

While politics exist at the bottom and the middle, at the top it is even more acute, and the stakes higherThe politics at the top is even more pervasive. Even the highest officer in the land has to contend with politics. The US president may have the most powerful military on earth, but his power over it is limited. Even he has to play games of give and take with senators and congressmen. He also has to engage the same games with countries ranging from the big ones like Russia and China, to small ones like Venezuela, and even with close allies such as Japan, Australia, and the UK.

Politics is as unavoidable and as necessary as grooming. Unfortunately, many nerds also tend to dislike grooming -- some cats have better grooming skills.

If you cannot avoid it, join it.

The first step is to embrace a new attitude toward politics. Politics is like Galactus. It is a "force of nature." Politics is neither immoral nor moral. It is to be likened to grooming, manners, eating from plates instead of cans, and common courtesy -- society expects them and woe to those who do not conform. There is no free lunch.

That is not representative of politics. There is no getting ahead without politics.

But...what is politics?