Category: Uncategorized Page 5 of 11

Why We Need to Outsmart Our Smart Devices

Why We Need to Outsmart Our Smart Devices

A valid point that needs addressing.

Beyond the Brainstorm

Beyond the Brainstorm

I’ve never trusted brainstorming to come up with ideas. This is a good list of alternative activities.

The Integration of Digital

Congratulations to Jason Davey and the folks at Bullseye on the their recent acquisition by Ogilvy.  From the press release:

“In addition, we’re now operating in a fast-paced post-digital era where having a separate digital team no longer makes sense.  We need to ensure digital is integrated into everything we do and not treated as a different channel. 
 …
 Fox said Bullseye’s Managing Director Jason Davey would move into a senior management role to oversee all digital output and ensure true integration.
 
Davey said of the move to become part of Ogilvy: “Specialist digital agencies are the dinosaurs of the future – it’s a natural evolution for a digital agency to broaden into a truly integrated offering. After 14 years growing our core digital capability, it’s exciting to be joining a world-class business such as Ogilvy to offer truly integrated customer experiences across all consumer touch points.”
My emphasis added.  
 

Market Stereotypes

Once you start looking for market stereotypes you can see them everywhere:
 
Market Stereotype Description  Examples
Competitive game Gaming performance where team’s are made of individuals with similar goals Sales team leaderboards 
Cooperative game Gaming performance where only team performance matters but individual team members contribute in different ways  Collaborative
workforce
management 
Discovery & scoring Add discovery of information by scoring of information and collective curation elancer 
Redundant production Make more than you need to find quality RFIs, competitive development
Unwanted feedback Ensuring feedback isn’t filtered Business Intelligence 
Interface versus interpretability Designing for unintended uses Open data
App store analogy
Using the model of an “app store” in a different context 
Defence app store initiative
Separate management from measurement Separate the management process from the measurement process Business intelligence + separate performance management function
KPI exchange Making a high-level metric tradable rather than using derived metrics Allowing employees to trade their “utilisation” performance metric
Lean business case  Making a market for project portfolio ideas; ensuring ideas are tested quickly while capturing intelligence  Idea factories
Agile development Dealing with uncertainty through iteration, continuous feedback, and no-fixed-plan Everywhere in IT
  
 
 
 
 
 
 
 
 
 
 
 

The Post-Productive Economy

The Post-Productive Economy

Choosing the Internet over running water when resourses are constrained.

We’ve been Weird Al’ed

http://blogs.wsj.com/speakeasy/2014/07/21/weird-al-yankovic-wraps-8-days-of-videos-with-mission-statement-exclusive/

Telstra Whitepaper: Analyse This, Predict That

‘Analyse This, Predict That’ – report on the major competitive forces facing financial institutions, focusing on data analytics and the way it is re-shaping the industry’s competitive environment.

http://www.aiia.com.au/blogpost/1151670/192356/Analyse-This-Predict-That

Susan Sly gives up on the CIO game

Susan Sly gives up on the CIO game

Who do the other execs blame for IT failure now?

Comparative advantage

Everybody's favourite economics lesson.

 

 

10 tips for successful business intelligence delivery

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

Page 5 of 11

Powered by WordPress & Theme by Anders Norén