Category: Technology-Enabled Business Transformation (TEBT) (Page 1 of 2)

Mega Projects Redux: Projects, Programmes, and Work streams (Part 1 & 2)

This is an article I wrote around 2002 that was eventually published on the Satyam (new Tech Mahindra) blog.  I can’t find the old Satyam blog now so here it is again.

 

Projects, Programmes, and Work streams (Part 1)

 

MegaProjects are large enough to be called a ‘programme’, but integrated enough to be called a ‘project’.  In the end, all MegaProjects must be run as a programme; but it’s important to understand why.  This is a slightly edited reprint of an article I wrote on delivering technology-enabled business transformation (TEBT) projects which describes the difference between a project and a work stream; and the challenges for project management on MegaProjects. 

 

If you talk to a project manager or a programme manager for long enough you risk getting into a very long conversation about the differences between project management, programme management, and portfolio management.  It’s easiest to define these first in terms of what a project is and secondly in terms of the objectives for grouping projects in certain ways:

 

1) A project utilises resources, has a specified duration, and delivers pre-defined objectives

 

2) A programme is a group of projects which are managed together as they relate to the same objectives and there are interdependencies between each projects’ deliverables

 

3 )A portfolio (of projects) is a group of projects which are managed together because they are part of the same organisation and therefore must have sufficient consistency in the way they are managed in order to manage resource allocation across projects, and risks across that organisation

 

There are added complexities around the definitions of operational vs. strategic programme and portfolio management.   Management of the dependencies between each project is separate from the management of the mix of projects in the programme or portfolio itself.  In other words, there is a difference between running a group of projects right (operational) and investing in the right group of projects (strategic).  For MegaProjects their duration means a certain amount of the strategic process is required, but we are focused here on the operational side of MegaProject management.

 

So is a MegaProject a project, or a programme?  

 

MegaProjects have two important characteristics that make them a unique challenge to the project management discipline.  Firstly, MegaProjects are indeed projects because they share a single set of phases and milestones and all resources will be affected in some way be the overall project lifecycle.  Secondly, MegaProjects must be managed as a programme in order to balance the need to manage accountability for deliverables within each part of the project and the need to manage dependencies across each part of the project.

 

Ultimately, all MegaProjects must be run as a programme.  However, although each MegaProject must be run as a programme this isn’t because MegaProjects are a collection of projects.  MegaProjects must be run as a programme because they will require more than one project manager!  This is a vitally important point that shouldn’t be under-estimated.  MegaProjects have objectives that are significant in scope and therefore are sufficient to require multiple project managers to deliver them.  It is for this reason alone that you must run MegaProjects as a programme.

 

Project managers behave in predictable ways: they want to define the criteria for success at the beginning of the project, they want to manage scope, and they want to freeze requirements at a certain point.  They will also expect access to the valuable time of stakeholders and subject matter experts.  For regular projects, all of these behaviors bound and align a project in order to improve the odds of the project being successful. 

 

These behaviors are the basis of good project management.  However, MegaProjects require additional monitoring and control mechanisms to ensure that these behaviors don’t guarantee success of part of the MegaProject at the expense of failure or bottlenecks in another part of the MegaProject.

 

Projects vs Work Streams

 

One of the keys to a successful MegaProject is correctly identifying which parts of the MegaProject are projects and which parts are work streams.  These projects and work streams can then be aligned through key programme-level processes which cross both types of activity.  

 

Next week’s article focuses on the differences between projects and work streams and how to define these within a MegaProject…

 

 

Projects, Programmes, and Work streams (Part 2)

 

In part 1 we saw that MegaProjects must be run as a programme primarily because multiple project managers will be required in order to execute the project.  Project managers behave in predicable ways and will try to manage the scope of their deliverables in order to achieve success for their part of the MegaProject.  To ensure success of part of the MegaProject isn’t at the expense of other parts of the MegaProject this article introduces the difference between Projects and Work streams.

 

Difference between projects and workstreams….

 

Workstreams

  • Scope tends to exist within only one or two areas of the TEBT programme planning worksheet
  • not directly connected to the objectives of the programme
  • fed work from other part of the programme in terms of level-2 requirements, defects, analysis requires, etc
  • managed as a ‘cost centre’ in that resources are fixed or leveraged as a pay-per-use managed service with a fixed budget
  • responsible for defining resource requirements based on solution

 

Projects 

  • directly accountable to objectives of the programme
  • scope defined across the business transformation objectives and at least 2 layers down the TEBT programme planning worksheet
  • utilises work streams for input or delivery of defined work packages
  • responsible for defining resource requirements based on objectives 

 

The TEBT Programme Planning worksheet also defines (on the left) some functional responsibilities (such as testing and implementation) which are by definition work streams.

 

Mention the programme phases, milestones, and the delivery roadmap… future post.  

 

 

Relationship to SDLC 

 

While it’s true that each piece of code must go through a software development lifecycle; pieces of code will be changed for the duration of the project so the programme itself is never at a stage in the software development lifecycle.  Also, MegaProjects produce many deliverables which are not code but that have relationships with code (and other deliverables that must be managed).

 

 

TEBT Programme Definition Worksheet

 

 

See  www.managewithoutthem.com/tebt/workstreamsandprojects.html

 

 

TEBT Phases 

 

Part of the delivery roadmap for the overall programme

  • Initiation
    • oDefine objectives, budget
    • oDetermine partners and capabilities required
  • Solution Blueprinting and Delivery Roadmap 
    • oDefine a cross-partner solution
    • oDefine a delivery roadmap 
  • Project & Workstream Definition
    • oDevelop project  and work stream accountabilities
    • oDevelop charters per project and work stream
  • Analyse and Planning per Project / Work Stream
    • oAllow initial analysis to complete for each work stream and project
    • oConfirm resource requirements
    • oConfirm dependencies across projects and work streams 
    • oDefine shared programme level processes
  • Development of Deliverables
    • oDevelopment of deliverables for each work stream
    • oExecution of shared ‘Development’ programme level processes
  • Integration of Deliverables
  • Test execution
  • Integrated test management
  • Implementation

 

Vendors may join or leave at various phases.

The No ICT Strategy Organisation

The idea of business / IT alignment is completely at odds with the challenge of business agility.  You can never align all-of-the-business with all-of-the-IT.  You can only ensure that the business capabilities your organisation’s operating model depends on sufficiently utilise information technology in order to ensure competitive levels of productivity, optimal customer experience, and coordination with other business capabilities.  
 
The idea of business / IT alignment is admirable when it implies that in model business operations there is a concept of “business” concerns and their is a concept of “IT” concerns and that they are peers.  The process of business / IT alignment then would be a messy and complex process that might eventually work.  However, business / IT alignment never gets implemented as a process that assumes business and IT are peers.  Even if it was, it’s foolish to break your organisation along the lines of business versus IT – there are other ways of cutting up the organisation that eliminate the need for business / IT alignment altogether.  
 
This is further exacerbated by the shift of IT budget to business units.  Once budget that had traditionally been thought of as IT budget gets shifted into, say, marketing, it would be ridiculous for the marketing department to then raise a concern about the business / IT alignment challenges they were having when spending their new increased budget.  Once you’re responsible for both why complain about alignment?  If you own the budget you have nobody to complain about business/IT alignment to.
 
I’ve written before about how much of what people in the so-called “business” think of as “IT issues” are really related to information, complexity, or simply willingness to spend time on the details.  When a business process is automated – does it then become an IT problem?  It is a sign that our understanding of the dynamics involved in the implementation of information systems – which it is now trendy to call “digitisation” – has certainly outpaced our popular understanding of how organisations are designed and governed when these simple questions still have complex answers.
 
We have a number of real problems governing our organisations.  Business and IT concerns aren’t ever broken down to specifics, the whole concept of splitting business and IT places barriers to true organisational agility, and there still isn’t an understanding that in the modern world the high-level concept of “the business” and “IT” don’t exist.  This separation is make for the convenience of executive leadership and have limited organisational value.  
 
I’ve previously proposed the simplest change might be to stop creating ICT strategies.  I’m not saying an overall strategy for certain aspects of IT isn’t required.  I’m simply saying that an overall strategy for the organisation is more important.  If you have a business strategy and an ICT strategy is it any wonder you have business / IT alignment issues?  Of course you have alignment issues!  You have two seperate strategies. 
 
This is exacerbated by the fact that your business / corporate strategy  probably doesn’t contain the sorts of things the folks developing your ICT strategy expect to see anyway.  They probably have to go to individual business unit strategies to get the information they need and ultimately the ICT  folks are left to try and align the inconsistencies that will inevitably exist between all of these business unit strategies.  
 
A strategy development and strategy deployment process grounded in business capabilities is of course the answer.  

Simple rules to direct your mobility spend

From my old notes. It should be a simple process to identify the opportunity space for innovation – in mobility for example – whereby a quick view of the total potential set of benefits can be identified.  It’s then just a matter of investment priorities and execution. Simple, right?

IMG_0066.PNG

Interesting Times at Westpac – Dave Curran, CIO

I would have loved to have seen the presentation that’s been given some positive press here.  Westpac are putting some meat around their transformation agenda after having learnt from the experiences of other banks.

Many of these large scale transformation programs (think ERPs, CRMs, core systems replacements, etc) have a tendency to teach the organisation about a product.  The whole organisation will learn how to implement that product – they’ll learn it’s strengths and weaknesses, and the right and wrong ways to successfully exploit them. Those in the organisation who aren’t part of the solution will at least learn that they have an opinion about these things.

Now, the actual benefits of these programs aside, this is a strange way to for your organisation to spend a few years.  These programs become a distraction that take up executive, management, and operational attention.  But what if you changed the conversations so that rather than learning about a product, you completed the same program but what you where really doing was learning about your customers and how to better orientate your organisation towards their needs?

I think the approach Dave Curran has managed to convey (again, based on the reporting – I wasn’t there) starts to do that.  This approach means that effort is first and foremost about the customer. Now I’m the first to say it’s not that simple.  There is still a lot of work to make that vision operational. But it completely changes what the organisation will primarily be learning during program.

The key lessons now will be about customers – what Westpac knows about them, what they don’t, what decisions they are making every day, and how that might be understood by Westpac staff when making their decisions.  The other lesson they will be learning is how technologies they already have, combined with technologies available in the market, can be used together to support various customer scenarios.  Not trying to find “the best” solution without any context, but trying to design solutions across a well informed view of what is important to customers.

I think too that if this is done right, the discussions won’t be broad sweeping generalisations. They won’t be “is this one monolithic system really customer focused?”  Likewise, there shouldn’t be that tendency to continuously revert to “yeah, but what is a customer?”  That conversation seems out-of-the-box but is typically only asked because the people in the room have never met a customer (!) so they revert to broad open questions rather than use their experience.

Done right, this approach will draw out rich, informed conversations that admit that we have to bring components together to support specific customer scenarios.  It will draw out conversation about what we don’t (!) and ensure we find out.  Done right, this approach keeps up the sustained momentum these programs need to do the hard work that will truly transform the organisation.  

I have a few grounding concepts that I think are relevant here.  They are quite simple in their nature but powerful as the basis for governing change.  I’d suggest these should be established for the program.

The Customer Advocacy Office

We talk about the importance of customers all the time but often the question we don’t ask is “what is the business unit in our organisation that advocates for our customers?”  I don’t mean lets give somebody the responsibility for customer and then split the role into “Contact Centre” and “Web site”.  I mean real, serious thinking about customers.  Being able to understand and back up with facts.  Being able to offer targeted operational changes – backed by evidence – that will improve the experience of customers.  

Customer Experience Campaigns 

Your organisation is probably comfortable with marketing campaigns.    But what if the concept of a campaign was expended to include any situation where your customer had a defining positive or negative experience with your brand?  Customer Experience Campaigns apply the basic concepts that are used to manage a marketing campaigns to all of the individual experiences of your customers.  This is actually really difficult, and really important.  And it’s what we mean when we say we want to be customer focused – but do we actually do it?

Customer Information Management

There is a lot of work required to get a single view of a customer.  There is even more work required to repurpose that view so that it highlights the information required for different groups to make decisions (i.e. single core data, multiple views).  But that’s still not “customer information” – that’s just consolidating and presenting data effectively.  A true responsibly for customer information management means knowing what you don’t know about your customers, and understanding the value of finding out.  It also means understanding how modern technology allows us to understand and predict the complex decisions that our customers are making by using big, social, cheap, integrated data to act as a proxy for intimacy when you can’t always get inside your customer’s heads.

Customer Return on Operations

Things like Net Promotor Score (NPS) are great but they are the tip of the iceberg when it comes to using customer-driven metrics to improve your organisation.  These “voice of the customer” metrics are great but they are “lag” indicators until you do the correlation required to make them “lead” indicators.  Measuring you customer return on operations combines how your customers think you perform with how you think you perform.  It’s hard, it takes a prolonged effort, but who could argue that it’s not important? 

Competency Centre -based Business Transformation 

Many transformation programs are top-down.  This means they are limited to the types of transformation that you can achieve top-down.  The Westpac approach will required a middle-out approach.  There are many functions within the organisation that will need to be transformed to execute on the vision.  Thankfully, competency-centre based business transformation is an excellent alternative to top-down transformation – if your transformation team “gets it”.  

This approach also includes the question of which type of “core” you want your organisation to have (accounting, versus product customisation, versus customer hub). When you’ve done the right homework, you can then make clear and informed decisions on whether something is differentiating or not differentiating. This decision drives standardisation but it is so mixed up in a tight bundle or current power struggles it needs an informed third party to arbitrate. 

I’m not saying just talk about the concepts above in the executive management team. I’m saying that in addition to the other governance required for this sort of program there are executive roles for each of the above areas.  There are charters and terms of reference for each of the above areas.  Each of these areas should be managed as a business capability where the executive in charge is responsible for working across functions so that the people, process, information, and technology all work together to support the capability.

 

By the way, I’m not sure I get the title “Dancing About Architecture” that the article  I link to above uses.  I’m assuming it’s a reference to the “Writing about music is like dancing about architecture” quote that I, like everybody else, mis-attributed to Elvis Costello until I just looked it up.  It’s a nice image – the idea that you might use something other than architecture (such as your customers) to guide the direction of your architecture.  You dance around (or “about”) your architecture so it knows where to look.  Though by alluding to the music quote the author seems critical of the approach.   Anyway – looking forward to part 2…

 

Cloud-First Policies vs. The Real Impact of Cloud

What a slow process it is to watch jurisdictions implement “cloud first” policies.  State and federal governments are all doing it and in the end they all look pretty similar.  Some might say it’s a policy of considered common sense, or a policy not to exclude the obvious.  At least the process is getting done.  
 
Though as I was reading the latest commentary on the Coalition’s new “cloud first” policy it struct me that this drawn out response is hiding some of the real impacts that Cloud will have. Not just as an obvious technology choice, but as a real disruptor to business and government.  
 
Of course, this “cloud first” mandate is always qualified – but it’s the nature of these qualifications that is telling.  In the case of the latest policy, the qualifications are simply that the Cloud solution also needs to be fit for purpose, competitively priced, and met the Protective Security Policy Framework.  So it’s a mandate to use the best approach even if it’s cloud. You’d wonder why you need a mandate to use the best approach so I’m sure the policy doesn’t fundamentally change the existing risk aversion, lake of knowledge and vision, or whatever else was stoping Cloud adoption in the first place.
 
As we know, the problem with mandates is that they tend to reduce individual accountability.  So the very real data governance and privacy issues relating to Cloud are likely to lose some attention for a while; particularly when paired with the removing of the need for double ministerial sigh-off for storing data off-shore.  I personally don’t see the problem with requiring double-ministerial sign-off to do something.  The only problem might be if I were one of the ministers who signed off and then something went wrong… Oh, hang on, I get it.
 
Problem is, like everything else, decisions are not just made by getting the right sign-offs.  You actually need to make the right decisions.  So policy that does nothing but try to gate decisions or make somebody accountable isn’t as useful as policy that actually helps decision-making.  There must be better uses for policy development effort than the use of Cloud as a technology choice.  Say for example as a disruption.  
 
The impact of Cloud on ICT strategy is that application architectures will be made up of silo’ed by highly functional applications that support a particular business function or customer touchpoint very well.  
 
These applications will also have imbedded analytics which already cover the management and operational decision-making relevant to the area they support.  
 
Integration will be achieved only where there is a business case to do so.  Except the integration imperative will be so strong – as its absence reduces enterprise agility – that there won’t be individual business cases for each integration.  Instead, a top-down approach such as enterprise information management (EIM) will be used to build a single cohesive business case for integration as part of a program of driven by information governance, analytics, business intelligence, and the recognition of what I call “core shared information”.
 
The impact of Could on organisational design is that the functional organisation is dead.  The ability to acquire cloud-based services that provide not only the application services, but in the case of business functions the backend management of the function itself, means functional organisation is no longer viable.  
 
The management trend where everything of value is being managed as “a cross-functional team” is now the norm.  The only thing left is to remove the functional organisation that created that language in the first place.  Functional organisation made it easier for managers (i.e. to shift across organisations, and also because they only had to understand how their function fits + strong stakeholder management) now managers have to be better at managing.  Though they also have better [cloud-enabled] management tools to help deal with this.  
 
Impact of cloud on information governance is that it’s time to disconnect Cloud from information governance and privacy issues.  Dumping the off-shore data double-ministieral sign-off policy because it happened to be inconvenient to Cloud initiatives is simple baby-with-the-bath-water stuff.  
 
Sending personal data off-shore is still a breech of Australian privacy legislation if this hasn’t been agreed with the individuals who own that private data.  Organisations are still at risk of legal action if damages occur due to mis-handing of personal data.  So this shouldn’t have ever been mixed up with Cloud.  
 
Impact of cloud on business strategy means that your differentiation cannot be based on what is easy to acquire – because value comes from scarcity not from abundance.  Actually this has always been the case but the impact of Cloud is the breadth and depth of things that are now easy to acquire.  
 
Your ERP was never going to differentiate you from your competitors.  But because it was expensive it was able to provide a competitive advantage at a pinch (as long as the business case held up after the inevitable cost overruns).  Now that ERPs and significantly more valuable targeted services are available in the cloud they are much easier to aquire.  So they have value, sure – but don’t have value as a differentiating feature of your organisation.
 
The impact of Cloud on government is that there are so many things that peer-to-peer markets can do better than government.  The government shouldn’t just be shifting the services they offer to cloud-based solutions. The government’s Cloud policy should be how does a cloud-enabled market solution remove the need for this government function?  How do we ensure services are more effectively targeted by using Cloud services to manage the market for services?
 
In a way, the impact of Cloud is nothing more than the impact of lower transaction costs played out on the acquisition of services.  Sure, it’s probably bigger than that be it will be called something else by the time it become outcome-as-a-service.  So for now “Cloud polices” are the place to ask the disruptive questions.  
 

Another example of Market-based Management: Kanban As an Economic Bargaining System for Portfolio Management

Principles

“1. Introduce a common unit of currency – must be scarce”
“2. Provide a marketplace for buyers to bid on units of supply using common unit of currency”
“3. Provide just-in-time information to promote market liquidity”

Industrialised Adhocracy and The Future of Work

Excellent overview on Industrialised Adhocracy and The Future of Work:

http://www.procurementandsupply.com/resource/David%20Moloney%20-%20Industrialised%20Adhocracy%20-%202nd%20CPO%20Exchange%20-%20July%202014.pdf

NewImage

Rats participating the markets

Okay, so this has the scientific due diligence of an art installation rather than an actual proof of utility.  But it shows why market-based management is so important.  

One project is Michael Marcovici’s Rat Trader. The book describes the training of laboratory rats to trade in foreign exchange and commodity futures markets. Marcovici says the rats “outperformed some of the world’s leading human fund managers.” The rats were trained to press a red or green button to give buy or sell signals, after listening to ticker tape movements represented as sounds. If they called the market right they were fed, if they called it wrong they got a small electric shock. Male and female rats performed equally well. The second generation of rattraders, cross-bred from the best performers in the first generation, appeared to have even better performance, although this is a preliminary result, according to the text. Marcovici’s plan, he writes, is to breed enough of them to set up a hedge fund.

From http://marginalrevolution.com/marginalrevolution/2014/09/hedge-fund-rats.html

If the above scenario actually works it means a dramatic change in the way we think about the “decision-making” part of the management process.

If the stream of data (think “big data”) can be processed by an arbitrary meat-based neural network – and proven to be effective – what is the point of performance management on the rats?

Customer centricity – solved

I just found a nice overview diagram (nice in content, not in style) where I thought I’d solved the problem of creating a customer-centric organisation just by breaking the challenge into its components.

It’s a year or so old but to be honest it still looks about right:

 

PDF:  The Problem of Customer Orientation is Largely Solved – if you have the will to implement

 

10 linchpin business performance improvement initiatives you should be running right now

It’s often difficult to understand how your portfolio of projects is actually helping your organisation deliver to its strategic goals. The problem is that the projects in the portfolio often don’t play a part in ensuring the overall portfolio is easy to navigate and cohesive. You need linchpin projects in your portfolio to hold the others together.

Linchpin

 

Linchpin projects are different to other projects in the portfolio. Linchpin projects don’t have a business case in the traditional sense – because they are strategically placed into the portfolio to hold it together, identify risks across the portfolio, and steer cross-project decision-making.
Linchpin projects are value-seeking initiatives that raise the value of the entire portfolio. In fact, linchpin projects represent the new normal for combining operations and program management in the digital economy.

Your current portfolio 

Your current project portfolio is probably made up of three types of projects:

  • That subset of projects that had a strong enough business case to make the cut at the expense of other projects
  • Projects that your organisation almost left too late, so are now critical – or projects that unanticipated changes in your operating environment have recently made critical, urgent, or “must haves”
  • Big, chunky, game-changing programs that have been initiated following a strategic analysis & planning process. These are often more of a top-down prioritisation of investment rather than a fully formed project, until a more comprehensive analysis of the full impacts is performed

The decisions that initiated each of these projects aren’t always perfect. But you have no choice but to plunge ahead with the projects. However, each of these types of projects presents challenges to the management of your portfolio as a whole:

  • You selected some projects at the expensive of others – but when and which of those forgone projects will become your next critical projects?
  • Critical projects that have now become urgent will need to take shortcuts – but what ensures these projects understand the shortcuts that are available, or to plan the follow-on work required when the projects are complete?
  • Strategic projects represent investment priorities which will have the greatest impact on your customers, asset utilisation, and business performance – but how do you incorporate the best knowledge you have of what influences these into the strategic project’s planning and execution? (Without putting all other projects on hold!)

Major projects versus linchpin projects

It’s a mistake to think of your major projects, or your strategic projects, as your linchpin projects. Major projects are often run as exceptions, so the transformational impact of these projects is often limited or followed by organisational fatigue or regression. Linchpin projects on the other hand inject specialised disciplines into the portfolio and in many cases don’t need to be large investments.
However, there is an opportunity for your major strategic programs to host a number of linchpin projects to get them started. The trick is knowing which linchpin projects you need…

Which linchpin projects do you need?

Regardless of your organisation, the following linchpin projects should be in your portfolio. The characteristics of your organisation and current strategic direction will only impact the size and approach for each of these initiatives.

Project 1. Business capability based governance
Our organisations shouldn’t have a primary governance model that divides the organisation into functions and then constantly proliferates the need for cross-functional teams. Social enterprises don’t require this approach – so your organisation’s primary governance should be mapped to business capabilities, not functions. This is also the first step in ensuring “business/IT alignment” – by stripping back the historic and arbitrary separation that is the root cause of misalignment.

Project 2. Customer journey design & customer experience campaigns
If you can’t point to artefacts which describe an idealised view of how your customers experience your organisation, then you haven’t done enough thinking about your customers – and you have nothing to orient your organisation towards customer outcomes. Equally, if you can’t point to specific customer-facing processes, technologies, and metrics that continuously direct the resources of your organisation towards reenforcing positive customer experience and recovering bad customer experience – then your customer journey design is just sitting on a shelf!

Project 3. Asset life-cycle, utilisation, yield, and pricing
Airlines, hotel chains, mining companies, and farmers understand yield. They understand that large expensive assets must be effectively carved up to service the right customers, at the right time, and for the right price. In the digital economy this same process must be applied to every organisation’s assets. If you don’t understand the utilisation on your major assets, and how projects can impact this, then you are running a business that provides a higher cost product – or your are running a unsustainable business.

Project 4. Core shared data strategy, information asset governance, and decommissioning
Unmanaged, the information in your organisation can get out of control. We have access to so much technology – information technology – that is supposed to help us manage information. So why are there so many copies of the same documents? Why can’t we rely on information we receive from other departments? And what is cut-and-paste if not investment in the problem instead of the solution? The solution is to systematically discover and invest in information assets across their end-to-end lifecycle – focusing in particular on the “core shared data” that is key to coordination across business units. Oh, and don’t forget you can’t ever throw data away unless you know what it’s worth (i.e. Business value) – but some data you can’t afford to keep (i.e. Privacy Act).

Project 5. Combined process, information, and user forums – fit-for-purpose scorecards
Your employees know what is wrong. But there are few mechanisms for feeding that learning into operational improvement initiatives. Lean and Six Sigma ™ come to mind – but that’s just details. Whenever your process team talks to people who should be following processes – capture the reasons why they’re not! Whenever you find yourself questioning a decision an employee has made – capture the missing information that caused the wrong decision to be made! Whenever somebody throws their keyboard across the room – ask them why! Better still – combine all of this into a single session which uncovers what is wrong around this place.

Project 6. Innovation funnel, lean business case, and start-up support
Innovation, or rather an entrepreneurial culture, starts with hiring entrepreneurs. But what if you can’t keep them? There are three reasons you can’t keep them: 1. You don’t recognise the good ones – because you don’t have an innovation funnel. 2. You frustrate them – because there are too many barriers to implementing business cases for change. 3. They can get better, cheaper start-up support in the market. These things are easy to fix and can be funded to the extent that you value innovation.

Project 7. Voice-of-the-customer operational alignment – Customer Return on Operations
It’s pretty easy to gather basic voice-of-the-customer data. For example, you can just asked the simple “How likely are you to recommend us to your friends? And why?” questions at the heart of Net Promotor Score (NPS). The hard part is doing something about it. You need to systematically determine what parts of your operations have the most impact on your customers. Management of “customer return on assets” will tell you most of what you need to know about how your projects are impacting your performance – from your customer’s perspective.

Project 8. Competency centres and change levers – The Machinery of Business Transformation
There are two ways to transform your organisation: you could run a heavy transformation program, and then an even heavier organisational change management initiative – and hope you get both right. Alternatively, you can manage to a transformation agenda – vision – and a portfolio of integrated competency centres – collaboration and continuous improvement towards that vision. If you know your own organisation’s portfolio of competency centres, their service catalogs, their customers, and the most effective channels and levers of change for your particular organisation, then implementing your whole project portfolio, and avoiding unintended consequences, becomes much easier.

Project 9. IT federation: shrinking corporate IT and embracing shadow IT
Even with your primary governance now focused on business capabilities (see Project 1) you still need to manage IT. But the difference is you need to manage all IT, in the only way you can in a post-Cloud, outsourced, and BYO world – federated IT. Learn to manage IT without ignoring what is out of your control and you’ll revolutionise productivity within your organisation while spending less than you did on IT services, architecture compliance, and generally inconveniencing your stakeholders by trying to be the cost and standardisation tzar.

Project 10. Who are we: purpose, culture, communications, and performance
Engage, decide, communicate. There is always another opportunity to reinforce what makes your organisation unique. There are ways of doing this that improve performance. Try them.

 

Page 1 of 2

Powered by WordPress & Theme by Anders Norén