Over the last few weeks I have overheard a couple of things that really tickled me, because of their brutal portrayal of some business truism, and because of the skill of the speaker in articulating:Continue Reading
Articles by Rich
R.A.T.S. Delegation
In writing a recent post for my other blog
about planning and delegation, I fell into a set of 4 principles that define how to delegate successfully. The principles are Responsibility, Accountability, Trust, Success or RATS.
Here is the excerpt from that post:
But in reality, delegation in leadership is not about getting other people to do the work. It is about leadership development. It is about participatory ownership.
Delegation is not dumping the work on someone, and watching to see whether they succeed or fail. Delegation is assigning responsibility, developing accountability, building trust and engineering success…Continue Reading
Software Engineering
I am not a fan of software methodologies, third party libraries, hyper-generalized frameworks or other so called productivity enhancers within the software development process. At the same time, I abhor the idea of a thousand developers at a thousand keyboards creating a thousand screens, features, pages and trying somehow to stitch them together into a cohesive software product.
What do I like? Small teams of smart developers who understand how to build small re-usable frameworks to solve problems that they have already solved, and are likely to need solving over and over. Guys and Gals who are likely to re-factor their initial solution into a mini-framework. Sometimes these frameworks “adhere” to each other, and grow into something more comprehensive. Other times they are simple labor saving through code re-use.Continue Reading
Starting Green
One of the most useless project management conventions I have ever worked with is the status stoplight or RAG status. From a simplicity perspective, it is designed to convey a general state of the project. Green means things are “OK”. Amber means things aren’t that OK. Red means things are not OK at all. The convention is to get the attention of stakeholders when the status changes from green to amber to red. It is a beacon, or warning signal that something needs to change.
When Task Estimates Fail
Of course, the only valid reason for estimation is prediction. We want to predict the cost and duration of delivery for some set of working software capabilities. If we didn’t care about time and cost, we wouldn’t waste our time trying to predict. We realize that software task estimates alone are insufficient for this prediction. But at the heart, the task estimates being predictable; correctly representing the work that the team needs to do within some finite predictable variance is essential. Task estimates are the core of the plan.Continue Reading
Fail Fast Furiously
The other day, I read a tweet by @gnat (nat torkington), saying that fail fast as a mantra was misleading – because the objective was to learn, not to fail.
Actually when I exhort people to fail fast, the objective is to retire a risk. Sure, learning is important, but what is really important to the delivery of software is retiring risk. Either we know something will work, or we know it won’t work. Risk retired, the rest is just work.
What is necessary to fail is a set of success criteria. If it doesn’t meet all the criteria (at the same time), it fails. So when you send your team down the path of a POC or a Spike – with the exhortation to “fail fast”, you also need to provide them with some hard criteria to compare their results against. These criteria should give you an ability to predict whether your POC or Spike has really retired the risk, or whether you are simply kicking the can.
Weaponized Metrics
Software teams hate metrics. They don’t like to estimate work. They don’t like to tell you how much progress they have made. I remember my first “team” project. PM asked me to estimate how long it would take me to finish a task I had never done before on a platform I was new to. I replied that I thought it would take me about 1 week. PM was furious, ya know, Jack over there could have that done before noon. You software developers are all alike, padding your estimates. And so it went the whole project.
To software developers, metrics are like uranium. It is a dangerous substance, waiting to be converted into a weapon, easily used by management to destroy the team’s morale, and worse, productivity.Continue Reading
Project Portfolio Management
Projects are not assets, they are liabilities. Like a future obligation, or a goal. When you manage a portfolio of liabilities, they have to be offset by assets. The process of project portfolio management is simply the management of flow of expenditure projected by each project, in time, compared with the projected flow of funding from defined sources.
When the projected funding is sufficient to cover the projected flow of project expenditure for all projects, no worries. When the projected funding is insufficient, decisions need to be made. We can take actions like: stop, slow, abbreviate projects or change the scope of projects to overcome the insufficiency.Continue Reading
Product Management
Product Management is something that should be easy to understand. The highest level goals of product management should be easy to articulate.
1) build a valuable product
2) maintain the value of a product relative to its customer community
3) manage the investment in the product, to ensure the best possible returnContinue Reading
When Firing Is Better
Sometimes it would just be easier, and better for all parties if we were honest and just “Fired their sorry asses!” It would be easier for management, because there is less corporate drama around firing and hiring than around a reorg, or implementing alternative staffing models, and RIF’s are either good (when the economy is going down) or bad (when it is going up), from a market analysts perspective – but firing ineffective employees and hiring new talent is always good.