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
Sometimes in life and work, we become convinced of a need to change before most of those around us. Either we read the tea leaves, or we see the bigger picture, or some how we just were able to jump through the problem straight to a potential solution. Maybe we have worked through all the analysis in our mind and have a detailed idea that could be a slam dunk, a quick win, or a major turn-around for the organization. The problem is simply that everyone else is stuck in the status quo. Maybe they don’t see the problem clearly yet, maybe they just are not willing give what change requires – or maybe they just see the obstacles to change as being unavoidable or worse, unforeseeable. Maybe they see the risk of the change as many times larger than the risk embedded in the problem.
You have tried telling them. You had tried to convince others that your idea is good, that it will work. You have “told them until you are blue in the face.” Somehow, you end up coming off as unhelpful. People generally get defensive when you try to tell them about the problem, you can’t even get the solution on the table.
Perhaps the issue is not that your analysis is weak, or your solution is not worthy, but only that it is not shared. How do you get others to share your perspective, and to help champion your ideas? How do you get them to understand that the status quo (which they have been working hard to build and keep going) is going to turn out to be insufficient to achieve the larger vision? How do you get them to “disinvest” themselves in the way things are, so that they can invest in a new idea? How do you get them to be open to your ideas, instead of getting defensive?Continue Reading
Functional Architecture as a discipline has been brewing for a few years now. I have been a “functional architect” for a software application, and have also been involved in functional architecture review of enterprise software programs. I won’t claim to know what functional architecture means in any universal sense, but having done this work, and been in this role, I can describe some functional architecture principles that I know are helpful to making software more valuable in an enterprise context.
Functional architecture has several aspects. 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
My current role is interesting. I am an internal IT consultant in a large financial corporation. As an internal consultant I am free to work on as many projects as I can juggle. My billing is only explicit when I work on capital projects. I spend more time talking than “working”. Most of my working is writing. Yes, making PowerPoint decks is considered writing.
Over the past year, most of my own internal consulting engagements have involved some coaching. Coaching leaders on the business side of our organization through projects with IT entanglement. Coaching IT leaders through adoption of new technology or practice patterns. Coaching project leads into positions of transparency and truth telling. Coaching different kinds of leaders through developing guiding principles that make all the little decisions easier. Interestingly enough, the coaching is not really what I was engaged to do. It simply flowed from my understanding of the needs of individuals in the project context to be successful.
Recently, I have been working with a number of external consultants. Teams, actually. Teams of consultants from big 5 firms. I have been attached to the same project as they have, and to them, I am a SME and a network adapter. I share my knowledge of organizational practice and my interpersonal network with them, so that they can get their deliverables accomplished.
What I often struggle with is the shallow depth of their analysis. Their engagements are short, usually in increments of 6 week intervals. They spend a lot of time collecting data but not really producing information. They have methodologies that I suppose would be effective if the data/information they were fed were appropriately scrubbed and semantically understood.Continue Reading
Generally, software falls into three classes; Apps, Tools, and Infrastructure.
Apps – or applications as they were formerly known – are software built to help a user do some valuable activity, like check a bank balance or edit digital images. While the end user must learn how to use it, an app is useful without further development. Some apps are configurable, so can work differently for different users or organizations, but they are still focused on solving problems or delivering value related to some specific functional domain.
Tools – are software that are more general purpose, but with a specific flavor – that they are designed so that users of these can use them to “fashion” applications for themselves or other groups of end users. Tools express their own user experience, but are not always immediately valuable without some “fashioning”. Tools can range from Microsoft Excel to Sharepoint to web content management systems like WordPress, to giant ERP systems like SAP or Peoplesoft. Many business intelligence product fall into this category.
Infrastructure – are software that really has no end user experience. They are designed completely as a foundation for other software to be built upon. This would include any software whose primary interaction mode is through API (application programming interfaces) or CLI (command line interface) patterns. Products like databases, middleware, application servers, application frameworks all fall into this category.
So why is it so confusing to people? Because technology has its own functional domains. These classes are not mutually exclusive, in that for one user it is an application and another it is a tool. With add-ons, extensions, or plug-ins it becomes even more confusing, as these constructs blur the lines between tools and applications even further. Plug-ins for a tool, may be applications focused on one functional domain.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
Leadership must recognize that momentum is lost when decisions are anti-climactic. As a leader, it is tempting to focus on the decisions as your primary responsibility – but that is only half of the problem. When decisions are not incisive, are not positive, result in no obvious actions or next steps – our responsibility is to keep the team from getting demotivated, confused, or de-focused. 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