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...

How Valuation is Really done, and what use is that Valuation model in M&A deals?

Two stories: In the early 80s, GM bought EDS (Electronic Data Systems). In the weeks before the acquisition was announced, an analyst in the Treasurer’s office at EDS was summoned by the CFO and asked to ‘model’ the share price of EDS. The analyst was a bit perplexed – after all, one could look up the share price in the Wall Street Journal (no internet in those days, remember).. but he did as he was bidden, sat down on his PC (IBM XT, I think it must have been in those days, and Lotus 123, not Excel) and put numbers into his spreadsheet that would justify the share price at the time - $25 or so. Took it to his CFO – CFO shook his head and gestured upwards with his thumbs.. back the analyst went to his PC, changed a couple of numbers in the projection and came up with $35. Surely the CFO would be happy now? No, he got the same response. But, by now, the analyst had gotten smarter too – he asked the CFO what he should have asked him in the first place – ‘what number are you looking for?’. The CFO told him - $44. Well, it didn’t take long to conjure up $44 on the spreadsheet – the CFO pronounced himself satisfied and took the spreadsheet up to the executive floor to show the CEO and Chairman and the rest of the bigwigs. When the acquisition was announced, at $44, our analyst naturally felt pleased – but he also wondered how the CFO knew the answer.. turns out he didn’t, it was just his best guess of what GM would be prepared to pay. Imagine the feelings of both the CFO and the analyst when it was later revealed that, the same day, there was a gentleman from GM in the building with an authorization his pocket from GM’s chairman, to pay $50 a share! Story number 2: I was once involved in a merger of equals (no names this time). There were 4 people present in the room – myself, the chairman of the acquiring company, and two senior executives representing the company to be acquired. The opening remark from one of these senior executives was – the two companies are pretty much the same size, aren’t they? So shall we just value them as equal? We all looked at each other and nodded – it took about 5 seconds for the valuation to be done! Needless to say, some Big $ company was given a huge fee to do the valuation, after the fact, of course – their role was to justify the number we had already agreed on. The fact is, valuation is explicitly a matter for negotiation – it is decided by negotiation, by each side trying to figure out what the other side will go by. There are excel sheets and ‘times revenue’ models and ‘P/E’ models, but they are all really just rules of thumb, to make sure the negotiation is not just going way off base. So is the valuation model useless? Why do I teach it to everyone as an essential tool of finance? For that, we need a third story: During the negotiation of several (not just one) of the acquisitions I have been part of, it is useful to have some basis for negotiation. If I say the company is worth 10 and the target company says it is worth 20, how do we converge? Should we just split the difference? What I usually do is pull out my excel spreadsheet and say, all right, let us see what it would take to justify 20 – pretty soon, it becomes obvious that, to justify a price of 20, the company would have to do something extraordinary and unprecedented, like achieving double the margins it normally manages, or growing twice as fast as it ever has in its history. Then the negotiation can begin – the point is, now we have something to discuss, other than ‘10’ or ‘20’.. the spreadsheet serves as a very useful negotiation tool. It is nothing more than that, but nothing less, also... is it useless? No. But is use is not what people think.

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!