Looking for Trouble!

I am looking for trouble! That is, I am looking for clients that can present me with difficult, messy, horrible challenges.

Forget the easy stuff! I want to help solve the worst problems you have:
  • Is it just not fun to be the boss? Is your work draining the life out of you? I have met plenty of smart, very intelligent managers at all levels who are  drowning in their work. Too many problems, not enough solutions, day after day. I've been there. I clawed myself out of the mess the hard way. Along the road, I found out how to make managing fun. I can show you how I did it, and help you find your own way. Let's be clear: It will not be an easy road. There will be plenty of challenges. I can promise you a lot of fun though, provided that you are willing to seriously try a couple of new things.
  • Do you have a great vision, but your organization just won't budge from its set course? I can help you find the pivot points you can push to make your organization turn. Part of my value proposition to you, is that I stay around and help you push. My job is done when you succeed.
  • Are the departments in your company at each other's throats instead of collaborating? They may be Accidental Adversaries. I can help you resolve the problems.
  • Did you lose some of your best people during the downturn? Now that the economy is looking up, you may be left behind, because you no longer have the key people you need. I can help. Even better, I can help you set things up so you your organization is a lot more resilient when the next recession hits.
  • Want to increase net profits, but you do not have the cash on hand to make heavy investments. I can help you. Most companies perform far below their potential. I can help you find the hidden capabilities and work with you to unleash them.
  • Are you providing what your customers say they want, but when you show it to them they turn around and buy from a competitor? Common problem, but it can be fixed. I can help you do it.
There are a few things you should know up front:
  • I screen clients. I do not take on a job unless both you and I believe I can add real value. That means you must be prepared to work with me, first on a preliminary diagnosis, then on determining the cost of the problem. The problem must cost something in terms of your objectives, so that it is worth solving for you. 
If my talents and experience does not suit the problem, I will pass on the commission. If I know someone with experience better suited to solving your problem, I will refer you to them.
  • I always have clear objectives. That means you and I will construct a simple mission statement in the form of an Intermediate Objective Map. This is a simple thing to do. Often, it takes only a couple of minutes. However, it is very important for the quality of my work. 
We will also set limits, that is, determine in broad terms what I am not allowed to do (at least not without talking to you first). For example, I have worked in situations where I cannot interview certain people, and where certain information must be confidential.
If we discover the objectives should change, no problem, but we do construct a new Intermediate Objective Map.
  • I have one boss. Companies are fraught with people who have conflicting agendas. I do not split my loyalty. We determine from the outset whom I work for, and I report to that person or entity (such as a board or steering group) only.
  • You must be prepared to participate in finding a solution. Depending on the problem, participation can range from reading weekly reports and having lunch once or twice a week, to participating in a hands on course, to leading a change team. There are three reasons: 
    • There is a lot of useful knowledge inside your head. I will need access to that knowledge, and your insights, in order to fully understand the problem.
    • You run your organization. I merely help, and for a limited time at that. You must be involved in solving the problem, because sooner or later you must take ownership of the solution. The earlier you do that, the easier it will be.
    • You should not become overly dependent on consultants like me. My ultimate goal is to help you achieve your full potential. If you need me to solve the same kind of problem twice, I have failed. (Working with me again for the fun of it is a different matter.)
  • I work according to three simple rules:
    • Treat the customer as a highly valued friend. I will work for you to the best of my ability. I will keep your confidences. I will be honest with you, even if the things I have to tell you are difficult to hear. Part of my job is telling you the things no one else in your organization can, or dares.
    • Go for Win-Win Solutions. I operate on the premise that there are almost always win-win solutions.
    • Go and find out for myself. I will think for myself. It is part of who I am. It is also a major part of my value to you. I can offer you a different perspective because I am an outside observer of your business. If you want different results from what you have, a different perspective is what you need.
Make 2010 your year! Email me, or call +46 708 56 23 65.

Comments

Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta
Read more