Monday, January 26, 2015
The rule of 72: help for arguing with your mother-in-law
Labels:
compounding,
doubling,
exchange rate,
inflation
Saturday, November 29, 2014
The Software Organization under EDT
The software organization under EDT (Enterprise Digital Transformation)
In this (coming) world, the way software will be written, delivered and deployed, will be radically different. Naturally, it will have consequences for organization structure, HR policies, and work processes.
Software will be developed, tested and deployed by small teams of 6-10 people, which may include members of the customer organization and, in some special cases, even end users. The same team will be responsible for design, development, testing, deployment maintenance and the continuous changes they will need to keep making to the software deployed.
The teams will operate entirely in agile scrum mode. They will, by definition, be self-governing teams, with little direction from higher levels. The contribution of each member will be crucial but impossible to measure, since it is the team who takes ownership. They will be coordinated by a scrum master, who is a member of the team. Reviews will consist of daily stand-ups of 10 minutes.
Because the teams will be working closely with customers and users, and may in fact include members of these outside organizations, security and privacy issues, i.p. protection etc. will take on a different hue.
People working on the teams will have to understand key aspects of the customer’s business, technology, and how the user actually uses the software – today, teams are required to understand only technology.
Testing as an independent activity will simply disappear…it will become an integral part of the design/dev/deploy process.
Consequences for organization structure:
The company will be just a collection of self-organizing teams. It is not clear what layers of management above this will actually do – SBU heads, delivery heads etc. will never know enough about the progress of the project to be able to guide and control it. If they insist on reviews, they will only slow it down, and speed will be at a premium in the new world.
How will we manage a portfolio of such projects? Who will assign people to them? Who will decide what the team does next, after the project is done? Does the project ever get done?
Certainly, account managers will be needed, to nurture the relationship with the customer. Product managers will also be needed, since the software deployments will increasingly look like products – with training, documentation, road maps and so on. But above this, it is not clear what value management can add.
These are troubling questions to which we do not have answers today.
Consequences for HR policies:
The only measurable performance will be of the scrum team, not of individuals. Ownership and accountability is with the team as a whole, not even with the scrum master. How will we reward and promote people? Promote them to what? To a largely meaningless managerial role? Not everyone will be fit for, or interested in, the roles of account manager and product manager.
What will be career paths for people? Do they spend their entire lives in one scrum team after another? Do they grow as experts in a certain domain or customer type?
Should we consider rewarding and promoting, not individuals, but the team, all together?
How do we train and develop people to play multiple, overlapping roles – in multiple technologies, for instance – and in domain, business and user experience? The team will have to include designers, developers, testers, and deployment specialists – and their roles will naturally overlap and even switch as people learn and grown within the team. How do we encourage this to happen faster?
Companies who answer these questions first, and best, will be leaders in EDT...
Tuesday, November 11, 2014
How Valuation is Really done, and what use is that Valuation model in M&A deals?
Monday, November 10, 2014
what NPV and IRR are really used for - not what the textbooks say!
Every textbook on finance will tell you that capital budgeting techniques (NPV, IRR and all the rest of it) are used by companies to make investment decisions.
My experience as a financial analyst and consultant tells me the truth is quite different..and quite a bit more subtle.
In practice this is what usually happens - a decision is made by management, generally on considerations like strategy, positioning, market opportunities -I would go so far as to assert that the more important a decision, the less it is driven by financial analysis. Utterly trivial decisions (that is, from a strategic point of view, trivial), may get decided by the 'numbers' alone -they may get done if the financial analysis shows it is a slam-dunk and only an idiot would not make the investment, whatever it is.. when the numbers overwhelmingly argue, cry out even, for an investment decision, it may get made, but not otherwise.. (an anecdote here - a lifetime ago, when I was a financial analyst, it was my doubtful privilege to take before finance committee a proposal to buy a slide-maker - this was in the days before ppts, of course. I thought I had done a marvelous analysis, with NPV and IRR all worked out, and the finance committee rejected my modest request for $200K, after giving me hell for about an hour. Next up was a proposal to build a data center for $15 M.. passed without discussion! Why? as my boss, the treasurer, was kind enough to explain to me,it is not because finance committee didn't like my face, it was just that the company is not in the business of making slides, so the slide machine had to be a slam-dunk, justified overwhelmingly by the numbers alone. The data centers, on the other hand, were the life-blood of the company..)
So, if NPV and IRR are not used to make decisions, not important ones anyway, what good are they. Here is an insight you will never find in any of the textbooks - they are used to structure the project so that the decision to invest gets justified! That is, not to decide whether to do the project, but to decide how to do the project. It is a guide to action, a playbook. After all, it is used mainly by middle-managers, not by CxOs. Remember, the role of middle management is not to make strategic decisions - it is their role to implement strategic decisions!
So is capital budgeting useless? Not at all - but not the way the finance textbooks think But them what would you expect? Finance textbooks are written by people who have never seen the real world!
Saturday, October 4, 2014
Why HR is so difficult..
Labels:
developing people,
HR,
impossible,
process,
role definition
Monday, May 12, 2014
On Pikkety and the future of capital
Thursday, May 8, 2014
The 98% syndrome
Subscribe to:
Posts (Atom)
