This weekend my colleague Martin van Borselaer wrote a blog post “Where Scrum Sucks” in which he argued that Scrum lacks the Business side of project control. Martin has successfully used a combination of Scrum and PRINCE2 to solve this problem in various projects.

I believe Martin is right that for some projects more control from a business perspective is needed. However, I don’t think that adding more layers of control is helping us in making better software. It widens the gap between the business and the production team and it takes another chunk out of the project budget. That’s not business value, working solutions are!

If all this project control is not helping to create better solutions, what does it give us but a formal process for dispute? An escalation path?

Maybe we should look at it from another perspective. If a project is so large that it needs multiple management layers and business roles to keep control, shouldn’t we reconsider its size? Can’t we make IT smaller, clearer and euh… cheaper?

What’s keeping us from a just do it approach?

Trust

Our customers don’t trust us and they have very good reason not to. As IT we have too often been unable to deliver what the business needs. Projects were too late, over budget and in the end they frequently didn’t even fit the business requirements.

We as IT professionals also don’t trust our customers. When I was working as a analyst / programmer, one of my managers had a saying: “customers, you can never estimate them low enough”. The result of this skepticism is thicker contracts, larger risk margins, etc.

Customers always complain about the results and they disagree with our perception of the requirements. And programmers always complain that the specifications are not clear enough.

So what do we do? We calculate for argument, creating top heavy projects by adding layer upon layer of overhead. Customers try to at least limit the financial risks by demanding fixed price / fixed date projects. IT in reply requires more and more formal procedures and stacks of requirement documents to hide behind.

I am sure that in most cases this is not needed. That we can get better results with lower budgets. How? By making IT smaller. By accepting that you can’t know everything up front and that you will run into changes. And, most importantly by working together as partners, with a shared and clear goal. To do this, we need trust. Trust that we can do the job and that we won’t overcharge or under staff.

We will have to earn this trust. That’s difficult and that’s why I like Scrum so much. With Scrum we can prove our success to a customer with only limited risk.

Scrum allows us to deliver a (potentially) shippable product in one month (one month!), from customer okay until release.

If it doesn’t work, the financial risk is limited. Okay, one month work is still an investment but a tiny one compared to the alternatives.

And if it does work (and in most cases it will), we can start to work together on getting results and gain more confidence with each iteration. Putting tangible results first and keeping project overhead to a minimum. That’s business value!

It starts with trust. And yet, trust is a very difficult thing to earn. Without it, the customer will demand more control and more management. In those situations, or if the challenge is too complex or too political, Martin’s combination is perfect. Especially if in time you are able to show the results, reduce the overhead and start working together.

That’s my tuppence worth…

In a previous post, I argued that the current practice of hiring external IT professionals is increasing rates for contractors with scarce skills.

Stacking of contracts is a very common practice that results in higher end rates and lower income for professionals and small specialist companies. This makes it harder to make a perfect match because (pre) selection is only done through resume filtering. Additionally it results in less control for the parties involved, as it’s almost impossible to synchronize all these contracts.

So how do we fix this? Can we?

I believe we need three basic things:

1. easily accessible information;
2. less intermediaries;
3. more transparency.

More information

Using Internet (euh… Google) we can find anything and everything. That includes project openings, if they are posted. Even at this moment almost any resource request in The Netherlands can be found at one of the many intermediary or aggregation sites.

A great open marketplace with good search options would make this even better. A central place where any company can post their requests themselves and where potential candidates may apply online or find the application details.

To add previous project feedback to the static resumes of our professionals, customers can search social networks like LinkedIn and find recommendations or even references.
Ideally both would be integrated into a new system, with job postings, project resumes, customer feedback, etc. I don’t think we are there jet, but there are no technical limitations.

Less Intermediaries

Jeff Jarvis wrote “middlemen are doomed” in his great book What Would Google Do. I agree.

We don’t need intermediaries and I think I’ve proven that. Well, maybe it’s not completely true, or at least not yet. A broker can make it easier for organizations to streamline their contracts and tax-related affairs. Still, that’s the only thing they need to do. Recruitment or hunting is no longer necessary if all open requests are publicly available and for everybody to see.

Dutch social security organization UWV already uses open marketplace for staffing external resources. The police of Amsterdam does the same through another system.

Even with less or no intermediaries or brokers, we will still have stacked contracts. A two-tier setup with a project owner and specialist subcontractors, like Andrej described in response to my earlier post, is viable and very common in other industries.

Transparency

The last thing that is needed, is probably the most difficult one: transparency. No more unknown stacking of contracts, no more hidden margins. Organizations should force openness from their (preferred) suppliers. Just add the following conditions to the contracts:

• preferred system integrators may only use their own staff for contracting, no subcontractors. For projects under their responsibility, it’s their own choice of course;
• brokers have to disclose their purchasing rate as part of the contract and they get a fixed fee for their services (i.e. a couple of € per hour);
• chaining of contract is not allowed: a broker can propose only freelancers or specialist working for the company they do business with.

I am sure that both end customers and professionals will be better off with these three simple conditions. If sourcing requests are freely available, everybody can apply. If no money is lost on margin upon margin, the end rate is always lower.

If everybody can apply for opportunities and rates are transparent, the end customer can make an informed decision and hire the best professional for their budget.

In an article in the Computable (Dutch IT newspaper) of September 18th. 2009, two IT recruitment companies are quoted who are doing something about this. A great start, let’s hope more will follow.

In the mean time, we can do something ourselves when working with a broker. Ask for transparency in the chain and in the rate. It’s simple, two questions: “is this your end customer?” and “what is your margin?”. If they don’t answer, you know you are losing money on them and I would look for another broker. Don’t worry, they all have the same requests. Work with the ones you can trust.

That’s my tuppence worth…

At the Oracle Business Club meeting I mentioned in my previous post, Marc Cornelissen was invited for a presentation. I was there for networking, so I was a little skeptical at first. That changed, because his presentation was very good and full of links to our business.

Marc Cornelissen is a Dutch polar traveler and professional adventurer. He basically goes on expeditions for a living. An inspiring individual who has seen much and is able to capture an audience with his enthusiasm.
Marc talked about his expedition to the geographical north pole he and his team undertook at the end of the last century. A demanding trip of about 700 kilometers in 70 days on skis and sleds. No helpers, no dogs… pure manpower.

His presentation focused on team building, team interaction and dealing with the unknown and the unexpected. Making an analogy to doing business in the current crisis. I personally also saw a lot of parallels to running high pressure, quick win projects. A bonus.

Marc presented a number of “insights” that helped make the expedition a success. I want to share some of them because I feel they fit in IT as well. As Marc presented in Dutch, I have translated them loosely.

Leave behind and move forward

When traveling on skis to the north pole, it is important to carry as little as possible. Choosing what to bring and parting with what you won’t need. Difficult, because you go into unknown territories and you can’t know up front what you’ll need. And you cannot linger or you’ll never move. So, choose and go.

For us, building solutions for customers, the leaving behind is more a mental thing. Leaving the past behind (known solutions, past projects) is essential for progress and innovation. Bring your experience, but don’t let it limit you in your creativity or your productivity. Implementing new technologies, changing business models and especially strong customer involvement require an out-of-the-box approach.

Decide and move

This is of course a natural follow up to the previous statement. It goes one step further though. During their expedition they had to sometime choose between going through rough terrain or move around it. They would discuss the options and select a route as a team. Some team members would always pick the straight but difficult route, other would smartly pick the best route for speed.

As an experiment, they decided to let the headman choose the direction without discussion. To their surprise, it didn’t matter which choice was made. The average gain was the exactly same, whether they would go straight through the rough or carefully around it. They traveled almost 50% quicker than before.

How much time is do we loose on project meetings and one on one debates? How much more productive would we be if the discovery on ice would apply to software engineering as well?

Too often have I seen discussions over details in design or architecture. Good specialists in disagreement over the best choice to make to be more productive, better compliant to standards or more ready for the future. Discussions over alternatives that are probably both good.

I believe that working in smaller teams on projects with strong visible deadlines will help. If the urgency is felt by everybody, it’s easier to decide and move. As we should.

Speak up, Agree, Confront

This one is better in Dutch: “spreek uit, spreek af, spreek aan”. In difficult conditions, conflicts are inevitable. Especially when working with the kind of ambitious individuals you need to meet goals and make deadlines.
Make sure everybody knows to speak their mind immediately if they have a problem or a disagreement. Get the team together and talk it through. Come to an agreement that every team member confirms and stick to it. Do not except people retracing an agreement and confront team members that do.

Agree on this approach when you are building team. For team members that can or will not work like this, Marc proposed another saying: “fit in, or f%$k off”.

Reach success from a shared basis

Traveling 700 kilometers on skies over ice and on floating sleds over open water takes everything. You have to depend on your team, help each other both physically as emotionally. The mental strength needed for such a journey is enormous. You can reach your goals only if you share the same determination to reach them.

When running Agile projects, especially with a Scrum approach, a common goal is essential as well. Common within the team and shared with the customer. Success is possible only if the goal is clear and the same for everybody involved. Even when technology is new en specifications are shifting.

All in all, Marc gave me enough to think about. His book, everybody got a copy, shows these and other insights as well. I’d like to quote one piece, that I find sums it all up.

Nothing is as inspiring as traveling in unknown terrain. It sharpens the senses and forces you to constantly learn, while at the same time you more and more learn to trust your own basis and build on it.

Even though the physical experience is quite different (understatement), this is still very similar to how I feel working in IT. If you want to be innovative, you have stay on your toes, learn, adapt to changes but still trust your basic understanding of the technology.

Marc Cornelissens book “Zuiver Noord” (Pure North)  can be ordered at his website.

That’s my tuppence worth…

At a meeting of the Dutch Oracle Business Club, I got talking with some other executives of consulting firms. One of the things we can all complain about is the strong decline in rates for our top professionals. A great topic for complaining discussion with some food and a drink or two.

Working in IT for a while, I noticed that especially the larger organizations have changed the process of hiring external staff in recent years. There are probably many reasons for this, the current crisis being one of the more obvious. The less than trusting feelings towards the IT industry after Y2K and the Internet bubble probably haven’t helped either.

Sourcing of IT contractors

Organizations, tired of paying too much for their IT contractors, moved their resourcing away from the projects to a central department. Very often, project managers were forced to send their resource requests to purchasing. And as you might expect, this does not always result in the best match. The IT world is complex, quickly changing and apparently it is difficult for an unskilled individual to know the difference between i.e. Java and JavaScript, MS SQL and MySQL or JEE and J2EE (there is no difference between JEE and J2EE, but try to explain that to a recruiter with J2EE on his wish list). IT skills are not easily compared like printing costs or office supplies and price vs. quality is not always directly evident from just a resume.

To get even better rates and safe some time, the resourcing or purchasing departments have “outsourced” the matching to brokers and intermediaries. With a tender, a number of preferred suppliers is selected based on not much more than revenue history and a proposed pricing level. In The Netherlands, I’ve seen this almost always result in a selection from the big IT firms, completed with one or two brokers. The preferred suppliers because they employ a large number of professionals and can do projects (plus it’s easy). The brokers to handle the smaller specialist companies like ours and the freelancers. All in the effort to save some money. Is it laziness or ignorance.

So now the project managers fill out a requirements form (basically a list of skills the candidate should have). Resourcing sends this list to the preferred suppliers who make a first selection. Resourcing filters this list down to 2 or 3 who are brought in for an intake and the best candidate.

This may not be a bad idea and it could even work for hiring very common profiles or staffing of large projects where the skills of one individual are not too important. There are however a number of problems and unwanted side effects.

So why isn’t this working?

The selection of candidates from a stack of resumes is rigid to say the least. I’ve seen PL/SQL programmers with 10 years experience being outperformed by a high flyer with only one project completed. How can you select that from the bits and bytes of a Word document? How many of the really experienced Oracle DBA’s have taken the time to get their OCP certification?

Because the pre-selection of candidates is done as far as away as possible from the team, selection on soft skills or “team fit” is extremely difficult. Only a small number of candidates is brought in front of the team, this may result in bad team performance. Even if all the hard skills match.

This is of course not the biggest problem. I strongly believe this practice actually increases the rate paid for top specialists. Or, alternatively, it reduces the quality customers can hire for the same budget.

The customer pays

Even in the current economic climate, some professionals are hard to find, even for the preferred suppliers. They will go out and find someone, a freelancer or maybe an employee of another IT supplier. And if they can’t find someone directly, somebody else may know somebody or they will look further as well. Sometimes this will create a stack of many contracts between the professional and the end customer. I have an example where we had to chain 5 contracts! Think about the legal implications of all these stacked contracts. Who is responsible? What control have you got left? And, because every link in the chain will add their own margin (sometimes a ridiculous percentage), the end customer pays a premium. In this particular example nearly twice what we were being offered!

That’s bad. Bad for smaller specialized companies, bad for customers and also bad for the professionals themselves. Professionals who have to live up to the paid end rate that has lost its direct link with the actual skill level.

Is this worth it? Does it indeed save enough money and time? Are projects running better for less?

I am confident it is not and I think I know a better way to do this. More about that later, though. For now, I’m looking forward to hear your opinions and experiences.

That’s my tuppence worth…

I’ve been toying with the idea to start a blog for a long time. I want to share my views on and enthusiasm for IT and its impact on business and daily life.

Information technology is changing faster and faster and it’s transformed the way we (could) do business tremendously as it has already transformed the way we communicate and spend our free time.

With my company Whitehorses, we provide high level Oracle and Java expertise and realize quick-wins for our customers. Anything outside those topics will go to this weblog.

Check out the About and My Profile section for more info about me and this site. I hope to be able to post on a regular basis and look forward to your additions, comment or disagreements.