Why don't deliver on December, 28th?

It's allways the same, bad project management done with MS Project or similar products. Even if it is complex and painful it is possible to plan resources, their availability, and holidays, and to do a resource planing for each task. OK, your staff may change while working on a longer task, but you can document this through subtasks. And there are also switches to tell Project to let you solve resource conflicts by hand because of the nightmare of automatic reorganization. Relations, dependencies, dates, all have to be set very carefully. But when it's done allright your project management tool can help you to visualize and manage importand aspects of your undertaking.

But most time no resources are planned, no holidays are entered, the vacations are ignored. Only tasks with a rough duration estimation and some of the most importand dependencies. And where does it end? In nicely documented and communicated delivery dates like December, 28th. *sigh*

Is it really so hard?

Forgotten software development tasks

It allways seems to be the same. Again I've heard about two different software development projects which are more in trouble than needed. The first one has no real requirements engineering and an unorganized process. There's a continous flow of new requirements which also flow unbundled, unpriorized, and continous into the development. As a result the software updates are short planned and testing is difficult. That's a noxious environment for the software quality and for the developers. I don't know very much about this project, but I've once been responsible to cleanup a project in an almost similar situation. The first step has been the establishment of an iterative process with timeboxes. I've choosen 6 weeks, but this depends on the individual project situation. The second step was the installation of my request management system, a simple web application for the management of requirements and issues. Finally I've set up a process of collecting and documenting the requirements and their dependencies, priorized them, and published the features of the next three releases - with decrescent likeliness. The result has been a steady development with predictable results for our customers. Additionally we've been able to do a better resource planning so that a part of the team had the time to dig into the sources and improve them.

The second project I've been told about had two cost estimations for the finalization. One seems to be relative realistic, following the opinion of the team members. It has been done through the current project manager, who has a very good reputation in his team. But the estimation is also high. The other one has been done through the his predecessor. His estimation is much lower. So even if he has been replaced due to his flop before, the management now follows him. The lower costs are much more convenient. I can't believe it, what's happening there? Doing software cost estimation is one of my interests. And I always get relative high numbers using the function point analysis and COCOMO II. The people around me are very often scared about those numbers and so they are sometimes not accepted. But when a project moves towards the end I often see that the estimated effort is almost accurate. So it makes no sense to tell oneself a lie.

Both cases show how software development consist of more than just coding. Capers Jones analyzed a lot of projects and categorized them into six different types: web, MIS, outsourcing, commercial, system, and military. These types have diferent numbers of activities and percentages of work effort per activity. The minimum number is 7 activities, the maximum 25. Take a look at the table inside the referenced document. It show's very good what to keep in mind when realizing a software project. And even if it is unpleasing it is just the truth.

Juggling multiple projects

Sometimes I'm wondering about myself how I'm handling all my different projects. Writing articles and book reviews for computer magazines, writing articles in my wiki (in German) and this blog, developing different software projects in Smalltalk, learning Scheme and realizing a first project with it, maintaining my server, and reading a lot. And all that beside my family and my job. Colleagues and friends also asked me allready.

But now I'm reading "The Myths of Innovation" by Scott Berkun. It's the second of his books I'm reading and even if I'm just at the beginning I can say that it is a very good book. And one part handles the importance of idling during the process of being creative. This pause is needed to allow the subconscious mind to think about the topic and to build the right idea out of the stuff developed before. This pause can be - and typically should be - really lazy. But sometimes switching the concentration to a different topic is also a kind of idling, related to the original topic.

And that's right, I often have the feeling that the work on a new project or with a new technology makes my mind free for the longer running projects. And afterwards I'm more productive. So everything is fine, I can go on, and I don't have to care. *smile*

List, priorize and link

One of the most importand tools in managing projects is the list. Lists are a really simple construct, so everyone understands them and work with them immediately. They are generally accepted. But a simple listing is just a medium, not very helpful. For your work as a responsible person in a software development project you'll need different lists, with different priorizations and links between them. By the way, one very easy to use single user tool for lists in terms of tables is Excel. That's one of the reasons why there's so much Management-by-Excel. *smile* Databases with web-frontends would do a much better job here.

What lists do you need? First of all it's the project vision. It doesn't have to be very detailed and the mission statements should cover clear user scenarios on a business process level. It's just an outline of what the final product will look like viewed as a whole. The contained statements have to be priorized by their importance for the customer. So his input is very importand. The result has to be a list with identifiable statements in a clear order from "must have" down to "nice to have". You know, this list can and will change while the project is in progress. But it builds the foundation for the next steps.

Based on the vision the list of features will be created. Each feature has to be linked to at least vision statement. Even non-functional requirements have to be listed as a feature and linked to a vision statement. If features without a clear vision statement exist that list isn't complete. Each feature inherits the major priority from the highest priorized linked vision statement. But typically there are much more features than vision statements. So they need a minor priorization controlling the order of equal major priorized. Additionally, to make this list useful for the daily work, you'll need a field where you name the responsible person for the realization and a simple status showing if the realization is in progress, finished, tested or if this feature is allready integrated. There's much more useful information, but keep in mind that this list shouln't be too complex. An optimal software could handle this in different views.

A very importand list you've got to maintain during the whole project is the risk management list. It contains individual risks, their possibility of an occurrence, their lost if they occur and counteractive measures. The possibility of occurence has to be defined in percentage, the list in a comperable size - most time this will be money. *smile* Both together multiplied result in the probable loss which controls the priorization. Risks can have multiple links to vision statements, features, or issues. But they also can be without a link, e.g. when the risk is based on the personnel situation.

As allready written above there's another type of lists: the issue list. An issue is typically a problem with the system or a former risk that occured. Each issue has also to be priorized in two steps. This time the first one is based on the quality of the issue as a "show stopper" down to "not so nice". The second priority is this time the priority of the linked vision statement, feature or risk.

Those few lists, maintained in an open accessable tool and used as a base for your daily work and communication will allready help a lot.

KISS, YAGNI, DRY

Most of you know these acronyms relating the style of programming. The principles behind them help to build a software that doesn't lose itself in the jungle of feature creep and stays maintainable during the application lifecycle. OK, they are not the only aspects to think about, but they are really important.

So, if they help a programmer in develop a good piece of software, why shouldn't they help a project manager accomplish a good project? Let's take a deeper look into each acronym.

KISS

Keep it simple, stupid - it can't be repeated often enough. There's so much literature or training about project management with many processes, standards, and documentation templates. Many of them are really good and very detailed. They show a broad spectrum of methods, formalities, and artefacts regarding their special subject. This may be the requirements engineering, software cost estimation, risk management, architecture and design, coding, testing, and much more. Each time specialists write about their own area of expertise providing a more than 100% solution for the topic. This is not bad, you get a very deep insight. But this does not mean that you shall use everything in your project.

Depending on your customer, your team, your management and inhouse standards all your partners have different needs. The customer is interested in a good consultation and a fulfillment of his requirements, your management has commercial requirements and needs a reporting, your QM has defined quality standards, and your developers need a productive environment with the right toolset. To achieve all you can use your know-how and build a superset of all demands together with a safety belt out of your books or trainings. But if you would draw this on a piece of paper you could see that this cloud contains by far too much overhead for you and many of the involved people. It is too much to remember everything and does not allow an undisturbed flow of work. The bureaucracy kills the productivity and creativity of your team.

YAGNI

You ain't gonna need it - so you've got to strip it down to the most important intersections and try to negotiate a priorization about each wish that's expressed by only one person or a single group. Try to compare how much each request is really worth and what it does cost to get a good argumentation basis. And also negotiate with yourself about the ideas out of your books and trainings. Even if processes and ideas really sound good and productive you've got to check if this is suitable for you project, your environment, and your situation. As a project manager you're a service provider for the customer, your team and the management. So parts of the work shouldn't be ends in itself.

DRY

Don't repeat yourself - define a clear and simple process, adjust it with your team, communicate it to everyone, publish it at a central place in your intranet with news announcements and a history, and take care that everybody gets informed if and why something changes. So, over the time, you change your environment to live its own simple and aligned process and the project management as an integral part of the software development instead of a disturbing evil ordered by the manager.

Team communication

A few days ago I've talked about process patterns. Those are templates for the own work in a team to support successful processes. Most of them are generally usable, some are special for software development. Today I'll talk about one of my favorites and the most importand: communication.

Regardless of which role you have in your team your work needs an exchange of information with your colleagues and customers. You'll find many informations about problems based on missing or wrong communication. Very often managers don't really talk with their team, much of the process or a choosen architecture is poorly described and their is almost no direct contact between the development team and the customer. The results are decisions based on the wrong starting basis, misinterpretations of requirements or process instructions and the steady increase of existing conflicts.

So one of the first steps is to get a clear picture of your personal environment. Whom do you communicate with? When? How? How much? Which role does this person have and how is your relation? Often it is very helpful to draw a small diagram showing these persons and the factors mentioned above.

It is also helping to document their pesonality types. I've used the Myers-Briggs Type Indicator (MBTI) here. It knows 16 basic personality types based on the four criterias

• Favorite World (Extraversion (E) or Intraversion(I)),
• Information (Sensing (S) or Intuition (N)),
• Decission (Thinking (T) or Feeling (F)), and
• Structure (Judging (J) or Perceiving(P)).

All those are not black and white, so there are many nuances. And you don't have to use the MBTI, there are different ones and each one is also discussed very controversial. But it helps in communicating with different people if you've made some thoughts about their personality. You've got to take each one how he is. Beside the informations for the direct communication with you, it may be helpful if you try to get some informations about the relations and communication in between those people. Sometimes there are conflicts, or some are acting very good together while you've got a problem with one of them. The reasons may be in the company history, in the types or somewhere else. If you consider this during you communication you may change all your lines into green.

It is also very important to choose the right way of communication. Today e-mails are written very fast but they are also clinical. And they don't support a quick agreement on a common wording and understanding. Here are face to face discussions in front of a whiteboard very productive. But the result isn't very formal and lasting. Mails, letters or documents are much better for this. So you've got to choose the right way different for what you want to achieve. Additionally it is necessary to choose the right communication frequency. Not too often to annoy your partner, but also not too seldom. If you're responsible for a team there's the really good way of Management by Walking Around (MBWA). It advises to

• do it to everyone,
• do it as often as you can,
• go by yourself,
• incorporate subordinate managers,
• ask questions,
• watch and listen,
• share your vision with them,
• work with them,
• bring good news,
• have fun,
• catch them while they are doing good work, and
• dont be critical.

Try it, it really improves the communication and everyone gets a better understanding and a better feeling.

OOP 2007 - Soft skills

The tracks on friday lasted the whole day. I've chosed "Social - never mind?" by Bernd Oestereich, Guido Zockoll, Uwe Vigenschow and Alexander Lenhard. They introduced into different communication models and techniques. Even if I've read much of it before it has been really interesting to hear it again. Beside communication basics the project environment, the technique of asking questions, typology, feedback and conclicts have been covered. All together emphasized my opinion that soft skills are really important for teamwork.

OOP 2007 - How to get an agile contract?

Clients for software projects should mostly be interested in the realization of their business requirements for a fair price. Agile processes try to achieve that working with strong communication with the customer and re-priorization of the requirements with each timeboxed iteration. But often project contracts are fixed-priced with an also fixed set of requirements that are seldom complete enough to build the system right. This is only suitable for products with only few changes over the lifecycle. To achieve an advantage for individual software which may change often and is very important for the business model the process needs to be more flexible. So one idea is a master contract with sub-contracts for each iteration, or a regular contract and many change requests. Both have many disadvantages. So a different model could be a kind of maintenance contract. This is an existing construct which only needs few modificationes and has almost no bureaucratic overhead. But also here it will be difficult to convince the client. I'll think a bit more about this idea.