If a little is good, then a bunch must be better, until it isn’t. I was having a conversation on the train the other day on the way home from work. I was sitting with an acquaintance that I ride with from time to time and we were both complaining about the week we were having. And we started to realize that we were both frustrated by a similar problem – but seen from a different view.
My friend told a story about how he had to travel on business and how he had found a hotel closer to his client’s offices so he wouldn’t need cab service. The problem was that the hotel was not part of his company’s preferred vendor list, and it was $10 more expensive than the hotel 30 minutes away that was preferred. His experience from previous trips showed that he spent $45 on cab fair, so the net savings would have still been $35. So far, so good. However, since the hotel was not a preferred vendor, his expense needed management approval. So he went to his manager, and yada, yada, yada – the CFO of his business unit had to sign the form before he could get his expenses approved, even with a $35 savings. My guess is that that the cost of all the management attention on this expense cost his company something close to $250. So much for the $35 savings – his little deviation from policy cost $215.Continue Reading
I have been away from this blog for a while. In fact, I don’t remember when I last posted (I looked it up it was May.) In my hiatus, I have worked on some other writing projects and spent some time with Zed A. Shaw’s excellent “Learn Python the Hard Way”. As a matter of fact I. will post my impressions of that book soon. Preview: It is an interesting take from an interesting guy at solving the coding bootstrap problem.’
Today I want to talk about something else that has been bothering me for a while. The notion of an elastic software delivery staff. This is not a new problem, in fact, it is as old as software. Fred Brooks wrote “The Mythical Man Month” almost 40 years ago, based on experience almost 50 years ago. I was introduced to that book in 1984 while I was studying computer graphics with Sam Uselton at the University of Tulsa.
When you haven’t tried to “run” a software delivery team or project, the tremendous wisdom in that book pretty much goes in one ear and out the other. You don’t have the experiential context to comprehend the problem space. When I read Scott Adams brilliant Dilbert comic strip today, I see much of the same problem space. There are types of work that don’t scale well. Our traditional strategies for elastic staffing that developed during the industrial age don’t really work effectively for this kind of work.Continue Reading
Current group I am working in is responsible for functional architecture. In spite of the fact that I don’t have any practical experience, I have been asked to help define a practice in Business Capability Modeling.
I think the reason for that is that I have some practical insight into the requirements that functional architecture or functional systems design places on a business capability model.
The most core principle of functional architecture involves the semantics of units of work. In fact business capability modeling is about defining the semantics of units of work – so there is my connection point.Continue Reading
In a recent post about consulting engagements, I talked about some of the challenges with consulting organizations and their standard practices. I thought maybe some might benefit from some insight. These are some specific suggestions for handling these kinds of challenges.
1) Consulting firms have “relationship” managers or “engagement” managers – these are people whose job on the project it is to ensure the customer is satisfied. It is their corporate mission to ensure that your company spends more money with them. They are sales people. They come to your project meetings, with a stated purpose of making sure that the project is smooth and successful. Their “other” purpose is to develop a deeper network in your organization, and to “discover” other opportunities for their firm to “help”. While they may have expertise, industry knowledge, and skills that help your organization, it is worthwhile to question whether they should be billable on your engagement.Continue Reading
I am in the middle of my umpteenth system replacement project. There are some universal assumptions that are endemic to the user community in every system replacement project. They are born of hope and frustration. They are almost universal.
1) The new system will do everything the old one does, only better.
2) The new system will support all of my existing processes and procedures without significant change.
3) The new system will be faster that the old system.
4) The new system will have better data quality than the old system.
5) The new system will address ALL of the shortcomings of the old system.
If you have ever done one of these projects, you know. They are assumptions that you must actively work against. They require a constant stream of communication to dispel. I offer you my rationale for why they are never, ever, true.Continue Reading
Its compensation season in many companies. Performance evaluations are either complete or in process, managers are deciding who will get more and who will get less. It can be a sore point for some employees, especially if their evaluation comes as a surprise. Its worse, when the employee does not have a way to fix it, or cannot understand what is required. Which gets to the basis of performance management – how does the manager add value to the performance of their staff?
Performance Management is Not…
…just filling out the review document and deciding who to reward and who not to reward. That is the least important part, and often the only part that a manager gets graded on. I have friends who work as managers for companies where performance management is boiled down to simply discriminating numerically between high performing and low performing staff members on their annual evaluation.Continue Reading
Spinning. Wheels are spinning. We go around in circles. Progress is illusory. Just when we think we are “getting somewhere”, we realize we are right back where we started. Its frustrating. I bet you’ve been there. I bet you’ve experienced this feeling in many different ways.
I have heard it called many things: “Paralysis by analysis”, “Chasing our tail”, “Go fetch”, “The circular imperative” to name a few.
The symptom is that no matter how we try, we can’t convince “them” to sign up and move forward. The team won’t adopt the recommended pattern. The boss won’t sponsor the proposal. The customer won’t sign the contract.Continue Reading
Last year, two goofballs from Norway released a song they thought would be funny, called “What does the fox say?” that turned into a viral hit. The concept for the song is that we know all the sounds the animals make, but not the fox.
Today, I want to talk about things our bosses say. Especially when things are not going well.
How did this happen? Who is responsible? Questions of disappointment.Continue Reading
Every programmer struggles with providing estimates. It is a universal truth of software development. Most of the time we go way too deep, try to be more precise than we have any reason to be. Many times we have fear driving our estimates – what if they are too big (will they cancel the project? or will they assign the work to someone else?) or worse, what if they are too small (will they fire me because I appear incompetent?).
Here are my top six tips for solving estimation challenges in software development projects:Continue Reading
Skill – The ability to execute a practice, process, or procedure successfully; the ability to accomplish.
Competence – The ability to increase or acquire skill over time; the ability to grow in capacity.
Talent – The ability to decide which skill is best to apply, and/or invent and execute practice, process, or procedure, where no skill exist with reasonable success, and/or the propensity to gain competence in acquired skills.
If you take the definitions above from my prior post, you will start to recognize that much of what IT does requires talent. That skill and competence deal primarily with repetitive activities, that support an essential certainty about their execution. While these activities require decision making, the decisions and the decision criteria are constrained, they follow patterns.
Those of you who have spent their careers in IT will recognize that many of the activities that IT professionals do are not repetitive. They require invention, hypothesis, or discovery. These activities present new and unconstrained decisions. In short, they require talent.Continue Reading