Everybody's favourite economics lesson.
Category: Uncategorized Page 6 of 11
Posted with BlogsyFrom my vault of old files.
This is very much a beginners edition – filled with my own personal opinion.
1. Having a “signed off design” is useless. In the rare scenario that the client has agreed that any change in the design will be a change request, congratulations you win! Your project will never finish.
2. Data quality will have an impact even when it’s “not in scope”. If when you mention data quality your project manager says “that’s not in scope”, sack them. Only if the business sponsor agrees that the solution doesn’t need to be tested, and that the integration or reporting components are allowed to fail without any explanatory error message if one potential explanation is that they have encountered unexpected data, is data quality “out of scope”. You need to answer the question “how do we detect and / or handle bad data?” and even if the answer is “we don’t” it’s still in scope.
3. Sometimes data isn’t available. If you want to scope your product at all you at least need to constrain the source systems. As soon as you do this – I.e. Limit you scope to less than all of the data in the world – there is a risk that the required data isn’t available. You should assign ownership of this risk and understand how the scenario will be funded.
4. There are only 8 types of products you are building: interfaces, one data acquisition frameworks, one “consolidated” data store, reports, cubes or equivalent, derived data logic, and data-marts, process support frameworks. The whole project team needs to know what these are (feel free to use more precise language to the point that the whole project team can still relate to it). The project manager is part of the project team.
5. If you don’t know how many of the above products you expect to build or update when you estimate your product you will fail. If you don’t know specially the names of each during each phase gate, status report, or iteration kick-off – you will fail. It is however, okay for these to change – in a controlled way. It’s likely that sometimes building an additional report doesn’t change the scope of the project. In fact, sometimes it’s a compromise you have to sell.
6. By the way, a “process support framework” is a framework that supports a process. These include meta-data management framework, data quality framework, semantic layer, business glossary, etc. If you have any of these in your solution, and don’t have equivalent business owners for the process components of each, you will fail. Don’t pretend you are using these unless you really have a plan to implement them properly. Ask your solution architect if these are part of your solution and unless they are also in your plan you need to consider taking them out and planning for re-work.
7. You must be able to answer the question “if we had this data, where would it be?” Which means a single consolidated data model linked to source systems and derived data logic. Use this model to track the status of your integration build – field by field.
8. Don’t skip data profiling and the related q&a sessions to understand the results. 80% of the data profile reports will be a waste of time. The rest will be valuable but likely require somebody to go and talk to the call centre, check an asset sticker, or open the operational system it came from.
9. Status reporting must include the following: status of each product(started, on hold, tested, accepted, etc), status of data quality issue log, status of data profiling and q&a log, status of the data model implementation and data availability.
10. If does not matter if the stakeholders don’t want to see the above level of detail. That is the detail required to understand where resources need to be allocated. You need to make them understand why it’s important.
Bonus tip #1o. If your project manager complains that the above list is from somebody who “doesn’t understand project management” – sack them.
IPOs delayed until you can afford the regulatory burden?:
Marc Andreessen:The compliance and reporting requirements are extremely burdensome for a small company. It requires fleets of lawyers and accountants who come in and do years of work. It’s this idea that if you control everything down to the nth detail, nothing will go wrong. It’s this bizarre, bureaucratic, top-down mentality that if only we could make everything predictable, then everything would be magic, everything would be wonderful.
It has the opposite effect. It’s biased enormously toward companies that are big enough to hire fleets of lawyers and accountants, biased against companies that are very young and for whom there’s still a lot of variability.
Manager by Design is effectively advocating better collaboration architectures.
What if Quality Journalism Isn’t? (by @baekdal) #insights
And this is the essence of the trouble newspapers are facing today. It’s not that we now live in a digital world, and that we are behaving in a different way. It’s that your editorial focus is to be the supermarket of news.
The New York Times is publishing 300 new articles every single day, and in their Innovation Report they discuss how to surface even more from their archives. This is the Walmart business model.
The problem with this model is that supermarkets only work when visiting the individual brands is too hard to do. That’s why we go to supermarkets. In the physical world, visiting 40 different stores just to get your groceries would take forever, so we prefer to only go to one place, the supermarket, where we can get everything… even if most of the other products there aren’t what we need.
Worth a read. Rather than decide that all of your customers are now different because they are “digital”, perhaps question your strategy.
The best definitions are sometimes tautologies:
“A business capability is defined as the desired ability for the organisation to deliver a defined outcome, as referred to when defining the organisation’s strategy, or within a hierarchy of capabilities that can be traced to those used to define the organisation’s strategy. Importantly, if it’s not being referred to during the definition of strategy, it’s not a capability. Each capability must encapsulate multiple functions and may not reference any particular function except in the definition of it’s implementation. There is no need for a capability’s implementation to be defined for it to be a valid capability.”
Worth a read:
I’ve heard Elliot Rodger’s voice before. I was expecting his manifesto to be incomprehensible madness—hoping for it to be—but it wasn’t. It’s a standard frustrated angry geeky guy manifesto, except for the part about mass murder.
Your Princess Is in Another Castle: Misogyny, Entitlement, and Nerds
Good segment.
Interesting comment that suggests Australia has a “resource curse” (though that expression isn’t used) not just in general but also specifically in relation to our resilience during the GFC.
Note to self:
# This weeks Q&A comes thanks to Seyran Dehbokry.
Seyran has worked as Business/Process Analyst in the variety of IT projects for over 6 years. She is currently a PHD student at the University Technology, Sydney, Australia where she is developing a cross-disciplinary Business Architecture framework applicable for Small and Medium Enterprises (SMEs). This research topic has been motivated by his industrial experience in performing Business Analysis in Enterprise Architecture projects in medium size organisations.
Here is her first question that has been raised in her recent research.
“The cloud computing technology has been considered as a technology initiative rather than a business transformation tool that solves business requirements. Not for all companies the cloud strategies and principles have become a clear perspective to configure and giving rise to cloud oriented business. The reason for this gap is that the technologies are adopted through a bottom up (technology need) approach. The main challenges for a businesses in using cloud computing technologies is architecting business services and capabilities to support cloud computing model and managing internal and external cloud capabilities. However this comes about as a realisation that architecture, from a cross-disciplinary perspective, is required to guide the definition, development and governance of business services that will be supported by the cloud technology.
Seyran’s question this week:-
Could Business Architecture facilitate migration toward the cloud in companies?”
—
# Answer
I believe that when done well business architecture is our best tool to facilitate migration towards cloud in companies. This is part of the reason I’m uncomfortable with the way enterprise architecture is often presented as an integrated stack across Business, Information, Application, and Infrastructure. Its use in these disruptive scenarios is one of the reasons why business architecture has value even when it isn’t integrated with those other layers.
I believe there are three tools that help facilitate migration towards the cloud in companies. These tools are actually also effective in facilitating other disruptive technology trends (big data, virtualisation, mobility, etc.):
1. the pre-technology business case
2. capability-based planning (i.e. business architecture)
3. the economics of the cloud
## The economics of the cloud
Starting with #3. I think you can talk about “the economics of the cloud” but you shouldn’t talk about “the business case for the cloud”. This is just a rephrasing of Seyran’s comment in the question about cloud initiates have typically been bottom-up, technology initiatives rather than business transformations.
While you shouldn’t talk about “the cloud business case” (because this is by definition a technology-driven approach) a rich understanding of how cloud changes the economics of the organisation is required whether the initiative is technology-driven or business-driven. Often this is forgotten when a business-driven approach is taken – you still need to understand the impact of the tech if not the tech itself.
The economics of the cloud – like other disruptive technologies – can be analyses through multiple dimensions: automation, service category progression, transaction costs, digital value chain, time shift, geography shift, risk shift.
a. Automation – i.e. basic automation of manual tasks. In the case of Cloud this largely occurs through the economies of scale within cloud providers themselves.
b. Service category progression – i.e. how does this raise the level of value for services that can be cost-effectively managed. Cloud already has IaaS, ASP, etc. but the ultimate might well be what I’d call “outcome-as-a-service”.
b. Transaction costs – i.e. if transaction costs are reduced by the technology how does that impact the boundaries of the firm or the ability to take market-based coordination approaches within the firm. In the case of cloud this means the ability to acquire resource coordination and collaboration technologies that bring market-based co-ordination into the firm.
c. Digital value chain (with apologies to Don Tapscott) – i.e. the ability to independently manage the value of service delivery versus the value of the information generated during service delivery. In the case of cloud this could both dis-aggregate and re-aggregate industries or business segments where previously the costs of outsourcing where too high.
d. Time shift – i.e. can the technology defer decisions or facilitate activities to more convenient times. In the case of cloud this can occur when capital investment decisions can be deferred, sometimes indefinitely. Another example might be reducing the lead time for capacity upgrades so that they directly mirror the business planning cycles rather than running separate IT planning cycles that need to predict business requirements ahead of business plans.
e. Geography shift – i.e. the economics of outsourcing and taking advantaged of differences in resource costs, etc. In the case of cloud this is a very similar economics to outsourcing in general.
f. Risk shift – i.e. how does this impact how risks are transferred or shared. In the case of cloud this can significantly shift at both b2b and b2c. A cloud service associated with a product can aggregate information on say health that can allow the risk of health issues with a consume to be transferred. (eg. if your Fitbit data was provided to your health insurance company do you get a lower premium? This is effectively enabled by cloud).
## The pre-technology business case
The “pre-technology business case” is simply a top down business case – or business case model – that defines the outcomes that would need to be achieved for a business unit or process for a given investment to have an acceptable return.
When applied in conjunction with an understanding of the economics of say cloud the impact of both the cost and benefits side of the business case can be adjusted.
With reduced budget being controlled by IT departments it won’t be up to IT departments to make a case for IT spending. However, there will always be a need to spend on information technology in order to keep up with potential competitive advantages.
The pre-technology business case does this. You might ask how this is different to a business case? In many ways it’s not. Except that it forces discussion of value prior to the involvement of the IT department.
Once the decision of value is clear any capabilities internal or external to the organisation can make effective bids to commit to that value. Given cloud is external to the organisation a mechanism to allow bids and commitments to value is vital.
## Capability-based planning
The capability-based planning governance and planning is an approach that makes the top-level governance of an organisation based on the capabilities in the business capability map – rather than functional or product-based approaches. Capability-based planning extends this governance approach to the way new initiates are planned.
This is best illustrated with my diagram here:
https://managewithoutthem.com/wp-content/uploads/2014/04/capability-based-planning-maturity.png
In short the capability-based planning approach is what allows the bidding and commitment to outcomes as discussed above.