Bottom up: knowing what you do

Raising a child has its problems. You can tell 42 times "don't run, you might fall", but actually having a little (innocent!) fall makes a more lasting impression. This doesn't mean that the parent is better off throwing the kid on the pavement. The parent tries to guide the child as good as it is able to, through the process of learning and experiencing. And this wisdom from someone who hasn't kids.

Links of Interest
Bottoms Up: Leadership Style For A Better World

Back to the kids in the organization. Starting the "new way of working" at the individual employee level raises the critique that the employees are too stupid to change. "They perform this job in this way for 30-years. These guys are too old to change." And more arguments like this one. Instructing employees to deliver you a process description that complies to a project-approach doesn't work. I agree. But a little guidance in the activity creates miracles.

The guidance should consist of answering the big 'why': why do we need a new process? Why should it look like this? You could provide everyone with this fabulous book. People should know why the game is played like this, that's the key to success.

To middle management who will get the role of customer 'visibility' should be the mantra. Schedules, budgets and results will be transparent. Issues will be made clear by the project manager, to avoid as much surprises as possible. That will probably sell itself. Some discipline from the customer is of course required. Ambitious goals with no budget and a very narrow timeframe will be killed from the start. The only thing made transparent is its impossibility. The visibility also makes it difficult to change your mind. Middle management can change their initial thoughts, but it's 100% clear minds are changed; it's impossible to claim you are saying the same thing as you always did. This can be a drawback for managers.

For technical employees, like programmers, the trick is to show them "better planning, is more relaxed". If for example programmers can provide the project manager with a perfect estimate on how long they need for a certain job, they can do their work in their own pace, without time schedules slipping and pressure building. Assuming the project manager doesn't slash every estimate by 50%. When this is clear, just show them the way to improve their ability to plan. Watts Humphrey [1995] has constructed a complete process for this. The essence is to let people record what they are doing, and how long it takes. They can see for themselves which tasks consume most time, so they can take action to improve them. It makes visible how long a certain tasks actually takes. When asked for an estimate they can make a more informed guess, based upon their records on previous tasks. "System X cost me 1 month. This one has a little more functionality, so I would estimate for this system 2 months."

So, filling in time sheets is the way to go? Not if you put it like that. Just read the previous paragraph again and compare it with using time sheets to control the programmers in a directive manner: "You are late! Why?", "This takes too long! Why?" You will be heading for a disaster.

Top down: best practices

Having all those individual employees improving themselves is not enough. First of all, from the top down incentives must be provided to keep the people going. It is after all extra workload, so someone should better appreciate it.

Finally, let someone in the organization collect all the lessons learned from the individuals, and summarize it as an integrated and coherent set of best practices. For this purpose, best practices are always better then a complete method, as the best practices are really invented here!

Until now it was all about what you could do as a project manager; the approach was self-centered, like a self help book: "How to get rich in a millisecond." You will come a long way on your own, but you will never reach the full potential, the fullest effect you can reach with this kind of negotiating style of software project management. This section will provide some insight in how to introduce some "elements" of projects into an organization and its employees.

Links of Interest
Social OODA Super Speedway
Driving On The OODA Highway

Don't think when your organization is already accustomed to doing projects, this section is not relevant for you. Surely, the "official way" of performing the projects is not in line with "The Flow of Stakes" (see chapter 1), and new people will always be added to the organization.

Not invented here

Do you know the best way to frustrate a perfectly good process? Give a directive. Tell the employees they have to work in a certain way. Tell them they must. You will see your oiled machinery get sabotaged and run into a definite hold. People are funny in this respect, if it concerns their own work, they want something to say about it. They want to determine how they work. When introducing a project style of working into an organization this is one of the main causes for failure.

Some years ago I experienced an organization where all projects were torpedoed by changing requirements. In a need to get a grip on the situation the project managers looked for techniques to control the situation. They found out they had it all, they installed already every procedure that they could find in literature. And still, the projects were sinking under the heavy burden of continuos change. By accident they stumbled across a project team member at the coffee machine claiming that "the procedure was installed, but no one was actually using it. The project manager issued this procedure out of the blue, so, it's his darn thing. Not mine."

This phenomenon has actually a name: the not-invented-here syndrome. Not accepting something because it's not yours. It's around you, more then you can imagine. Why am I telling you this at this moment? Because a lot of introductions on doing projects are directives from above: "starting next month you will have to make a plan for every work you do; you have to record all the time you spend on tasks." And like I started out this section, that is a good way to frustrate a process.

Next to this "acceptance" issue is another argument to let the people involved determine the way thy shall work… who knows better how to work, then the people performing the job?

If giving a directive is not a good way to introduce it, what will be the alternative for the top down approach? Well… How about bottom up?

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.