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?

Upon Taking on a Project

Project management is concerned with effecting a desired change. The first step is to be clear and understand two questions:

• What change does the project owner want?
• Why do they think this change desirable?

The first question clarifies what change needs to be done and provides an initial glimpse into the objective of the project. The second question helps us to understand the problem with the current situation.

Risk Management and Alligators

I read once in a project management book, very likely from one of many that James P. Lewis wrote, where projects risks are described as being like alligators over which you have to jump over in order to complete the project. The menacing reptiles may or may try to bite you, and if they do, they may or may not succeed. Risk management is a tool you can use to get you past the alligators alive and well.

I think the imagery can be further adjusted to fit reality a little better. In many projects we are racing to complete the project against competition or against time. In other words, we don't just need to get past the alligators, we need to do so quickly because there are hungry wolves tearing down behind us.

If we adopt this revised imagery, we begin to see clearly that there are trade-offs that must be faced. If there are hungry wolves closing in, we may need to get across now. We may not have the luxury of waiting for the alligators to sleep before attempting to cross. We are now able to accept greater risk. Yes, we might get a chunk of our rump bitten off by an alligator, but the razor sharp alternative is coming in fast.

Managing Web Projects, Part IV

We continue the review of J. Rodney Turner's book. In chapter 2, Turner discusses what distinguishes web projects from other projects, especially other IT/IS projects. He argues that web projects are a subset of IT/IS projects but have enough differences to make them distinct. When Turner writes that there are at least 10 key differences, I thought that would be a large number. After all, besides the technology used, how else are web projects different from IS project, as projects? The key differences he lists include: - shorter time horizons - global reach with diverse user requirements - managed from outside the IS department - multidisciplinary teams with high focus on creativity and usability - wider range of user requirements - diverse technologies - immature industry with skills shortage - undefined methodologies - fast changes in the industry - perceived greater risk. Note that the focus of the distinction is on the project, and not the product itself. That is, the focus is on the experiential difference in the undertaking of a web project versus that of a typical IS project.

Managing Web Projects Part III

Chapter 1 of the book comes before Part I and is intended to be a brief introduction to project management. While it's generally an excellent coverage with lots of useful insights, I'm not sure about the wisdom of trying to introduce project management in such a short chapter. Especially when you give a definition of what a project is that is almost heretical:

A project is a temporary organization to which resources are assigned to undertake a unique, novel and transient endeavour managing the inherent uncertainty and need for integration in order to deliver beneficial change objectives (emphasis mine).

I think the chapter needed more space -- the subject it tries to cover is too big and only very briefly touches on the obligatory discussion of a project life-cycles.

There is a brief discussion on the importance of seeing a project at various levels, and some advise against prematurely planning the lower levels of a project before the higher levels are clearly understood.

His discussion of business objectives are also useful. Business objectives are the reasons why the organization is spending time and resources on the project, and they are different from the project objectives. Only after and if the project gets finished does the business begins to reap the business objectives.

A short and sweet discussion of the difference between cultural objective is also presented. Projects often focus only on the technical objectives ('build and install software') and the cultural objectives ('user training', 'creation of new procedures because of the new software'). This is a good reminder for the project planners.

Some of the valuable insights come from his discussion of project typologies. For example, he presents a typology of a project's importance to the business. Is the project intended to keep the business alive? Is it intended to reposition the business? Is it intended to improve business performance?

Finally there is also a brief discussion on the uniqueness of a project. While linguists may get riled when some things are said to be more unique than others, the world of project management seems to have latched on to the word. Turner presents a typology based in the uniqueness of projects. The classifications range from Runners, which are projects that are very similar to other projects undertaken by the project team, to Repeaters , which are projects common to the organization itself, but not to the project team, to Strangers, which are less familiar to the organization, having undertaken a few similar projects, to Aliens, which are totally new projects. The importance of this typology is that it highlights the risk inherent in the type of project, with Stranger projects bringing the highest risk.

In chapter 2, Turner begins describing what is special with web projects.

Managing Web Projects Part II

Continuing the review of J. Rodney Turner's book.

It seems many people who read books ignore the Preface. I'm not one of them, and I don't understand why people skip it. The Preface is the author's personal message to you, dear reader, about their intention in writing the book, and how they intend it to change you, as well as change you into what. Why would you not want to know about that?

Upon opening a book, I go directly to the Preface right after briefly flipping through the pages (mostly to filter out books that use size L or XL fonts). After reading the Preface, then I start to take in the smell of the paper, but let's not go into that.

In his Preface, Turner reveals that this book is the first of a projected series of books on specific applications of project management. Perhaps sensing that he needs to undertake a defense of the need for such a series, he elaborates that although he agrees with the opinion of many, that project management is a generic skill, nevertheless, different types of projects have different needs and therefore require different methodologies.

Comparing project management with other professions, such as medicine, law, and accounting, Turner observes that while these three, like project management, are generic professions, each has its own sub-specialty.

You probably do not want a specialist in corporate-law to defend you in a criminal case (viz. when Sherman's lawyer acquaintance turns him down in The Bonfire of the Vanities). Neither do you want a neuro-surgeon to deliver your baby (Dr. Brown of the Everwood TV Series notwithstanding).

Turner points out some revelations he had while researching and working on the book:

- General managers (rather than IS managers) tend to end up being handed responsibility for delivering web projects.

- Change management seems to be much more important than he initially thought.

- Web projects tend to be managed whole, rather than delivered piece-meal. In consequence, he discovers that techniques like agile management or extreme programming were not as central as he initially expected.

I was initially confused by those observations: why would piece-meal deliveries espoused by agile techniques not be central? Isn't the changing nature of web pages a perfect match for agile software development? And why would change management be important in a web development project where quick delivery is the expectation? Who has time for change management?

Peeking inside, I realised that in the context of the book, Turner was not speaking about simply developing web applications, but also about web-enabling business operations. That is why general management plays larger role. That is why change management is fundamental (not change control management, as I originally thought), and that is why the project tends to be delivered whole.

The type of projects covered by the book possibly makes this book less interesting for technical managers interested in managing web-based software alone, but it does make it more interesting to me.

In the next posting on this subject, we will look at chapter 1.

Managing Web Projects Part I

Just received a copy of J. Rodney Turner's newish book : Managing Web Projects (The Management of Large Projects and Programmes for Web-space Delivery).

I'm a fan of Turner. His handbook is, to me, a serious candidate for the title of the-only-project-management-book-you-need. It fails the criteria, of course. No single book will pass and I would consider it doubtful that any collection of 5 books will pass.

Amazon prices it at US$89.95. At 228 pages, it's likely to be priced beyond the willingness of many people interested in learning about managing web projects. How many other good books can you purchase with that cash?

I will be reading this book and reviewing it in these blog pages over the time I read it. I just borrowed my copy. Let's see if it's worth the price tag.

On the Nature of an Activity

An undertaking (i.e., a project) consists of many activities required to complete the undertaking. Failure of one or more activities eventually cascade and bring about failure somewhere in the undertaking.

Understanding the nature of activities help us understand its effects on the undertaking -- i.e., the project.

A typical activity requires people to perform the activity. The fact that people are required to undertake an activity implies a secondary activity -- assigning people to that activity, which implies other activities -- deciding (an activity) what kind of person is best suited for that activity, deciding where we can get that kind of person, etc.

Activites also require resources. To paint a wall requires not just a painter, but also paint. And brush. And newspapers to line the floor.

An activity takes time. Painting a room may take a day or so, not counting the time required to let the paint smell to dissipate to safe levels.

Activities cost money as well. Whether you hire a painter or do the job yourself, some cost is involved. You can pay for the services of a painter, or give up your time for doing other profitable activities in exchange for painting.

Activites have an end result. In our example, the end result is a painted wall.

Activities have constraints. You cannot start to paint a wall and then decide to stop midpoint. You cannot go back conveniently.

Activities may fail. A good painter may produce an evenly painted surface, but a bad one may end up with bumps and visible drips.

Lastly, once the wall has been painted, there remains some cleanup work to do.

To summarise:

An activity:

• Requires preparatory activities
  
• Has an output
• Requires material resources
• Requires people to undertake the activity
• Takes time to finish
  
• Has constraints
• May fail
  
• Has closing activities

Project Management

Every undertaking, faces the possibility of taking longer than anticipated, costing more than expected, and or not completing successfuly. The bigger the undertaking, the bigger the likelihood that unwanted events and outcomes occur.  One key culprit is complexity.

Consider the undertaking of changing your shower curtain versus the problem of defending Normandy beach from Allied invasion.  You might slip on the floor and bang your head seriously while doing the former.  However, many, many more things could go wrong more seriously in the latter (and many things did go wrong).

Launching an invasion is more complex than changing a shower curtain. It is this (vast) difference in complexity that makes the other undertaking much more likely to have potential problems. Complexity is like having many open doors and windows where problems are free to let themselves in. The more complex the undertaking, the more numerous the open doors and windows.

We could stay small and be content with simple undertakings, but our society's progress will be limited. We can choose to limit our undertakings to nothing more complex than mastering the art of candle-making, but our society will not progress much. If we want progress, we have to face and deal and master complexity.

Fortunately, we have tools at our disposal.

Look at the skyscrapers and other technical marvels we now have.  Science and engineering has progressed such that it is now possible to design buildings that will not randomly fall down and will even resist powerful earthquakes. We now know how to design such buildings. Complexity and its associated problems have been reduced by scientific and engineering knowledge.

But we like to push the envelope, and so complexity remains.

Every undertaking requires activities. No activity, no undertaking. The more complex the undertaking, the more numerous and varied the activities are.

Activities depend on and interact with other activities, and therefore must be coordinated. Those who need to fit glass windows to a building cannot start working until the building structure has been built. Those who need to test software cannot begin until there is some software to test.

Knowing how to design a building is not the same as knowing how to organise the activities required to build that building, and vice versa.  The orchestration of these activities is also different and demand a different kind of knowledge, attention, and discipline from that required to design a building or build a building.

To harness the benefits of science and engineering, there is another discipline that was developed to help us with our complex undertakings. This discipline is intended to help us manage the activities and ensure that:

• We can have a confident estimation how long a undertaking will take, so we can plan for it.
• We can have a confident estimation how much the undertaking will cost
• We can identify the activities required to complete the undertaking.
• We can ensure that the undertaking will take no longer than planned
• We can ensure that the undertaking will cost no more than planned.
• We can ensure that the undertaking will be completed.
• Everyone's valid expectations are met.

That discipline is called Project Management.