Can "Plan Buy Run" be more agile?

In an earlier blog post I explained some advantages and disadvantages of the "Plan Buy Run" [PBR] model / approach to IT management.
Note: Yes, I know the term is usually "Plan Build Run" - but how many larger organisations these days build everything from scratch

This approach is more "waterfall" in its delivery, which can be effective for organisations that need a clear and structured approach to IT. But it also means they are more subject to the typical issues of:

• Inflexibility: changes made in one phase can have a ripple effect on other phases.
• Delays: as each phase is completed sequentially before the next phase begins, delays earlier one create a shift in the end delivery date
• Lack of innovation: IT is focused on maintaining existing systems and applications rather than introducing new ones.

However some organizations have successfully adopted a more hybrid approach to the PBR model, where the waterfall phases are combined with agile techniques. This approach allows them to deliver new features and functionality to users / customers faster while still maintaining control over costs and risks.

PDB and agile can run in a hybrid way across the Plan, Buy and also the Run phases.

For example:

• Use agile principles and practices in the planning phase: 
  This involves business stakeholders in the planning process, creating short-term plans that can be easily changed, and focusing on delivering value to the business.
• Use agile methods for building and deploying new IT systems: 
  This uses iterative and incremental development, working in small teams, and getting feedback from users early and often.
• Use agile approaches for operating and maintaining existing IT systems: 
  This utilises continuous improvement techniques, automating tasks, and responding quickly to changes in business (and especially Non-Functional) requirements.

And ultimately there is no one-size-fits-all approach. The best approach will vary depending on the specific organisation's needs, circumstances and resources.

Picking what NOT to do is an IT Strategy

Technology change and progress never stops. There is always a newer version, a better alternative piece of software or another way of supporting an evolved business process or two.

For internal technology departments and especially those within larger organisations, this rate of change means there's never an end in sight. In a world of infinite need and finite resources... there's usually a long list of things to do once the current projects & programmes have been delivered.

With all this demand and the expected pace of implementation (that can come from all angles including: business stakeholders, vendor sales people and consultants) it can feel like everyone wants to change everything at once:
New finance system? Yes
New HR software? Sure
New B2C website? Of course
New B2B website? No problem
New sales portal? Yeah
New customer data platform? Naturally

Faced with a these requests, perhaps along with a potential new-found investment in technology to fuel a "digital transformation", senior IT people will want to say yes. Who wouldn't want more resources, increased budgets, the chance for some new "toys" or the opportunity to stick a big 'look what I've done' post on their LinkedIn profile?

But like the proverbial plate spinner, who (theoretically at least) should know how many plates they can spin at once... those in a position to take on technical work need to understand how much change they can take implement before they hear the sound of virtual crockery smashing. Experience needs to inform them (and so do their managers, subordinates and peers) just how much change their organisation can take on in parallel.

But when the demand for so much change outpaces the organisation's ability to deal with that change, someone has make the important decision as to what to do and therefore what NOT to do. 

Nobody, least of all IT people (prehistorically noted for saying "the answer is no, now what's the question?") want to tell a business stakeholder that their project is less important than another... but sometimes there is only so much change you can do at once.

The ever-increasing consumerisation of IT

So, according to the latest news… enterprises now buy 50% of their software without IT involvement. Does this figure come as a shock to those of us that have foot in both the Business and Technology sectors? Yup... kinda!

There is no doubt that the consumerisation of IT is having a significant effect on businesses, with many different lines-of-business having their own very healthy budgets to procure technology that supports their day-to-day work and often without getting the IT department of an organisation involved. Online applications, software as a service (SaaS) and the general rise of digital service subscriptions over the last decade or so have added to the on-going cost of technology that is out of the hands of the very people who used to procure, manage and support it.

And just as one hand gives (functionality to the business) the other takes away (control and coordination from the IT department). Which in-turn means less budget and potentially less staff are needed… which brings its own complications: IT staff are spread more thinly, they are only brought in when a system needs fixing and they now may have to face-off to highly competent technologists in Finance, Sales or HR.

Is IT using the wrong names?

It must be hard for those following the IT Industry as it grows and errrr.... develops.
Recruitment agents, journalists, senior managers, HR / Talent people, etc. They must all think we make up terms just to baffle them.

Let's take a few:

Puppet
A technology for automatically deploying servers to an environment.
Not a doll or a Thunderbird pilot.

Chef
A continuous deployment devops tool for groups.
Not a Sweedish muppet (see above) or a cleaver wielding ego maniac who now sells stock cubes.

Containers
An approach to software development where which pieces of code are packaged in a standardized way for subsequent reuse.
Not a metal box you see by the docks.

However.... perhaps us technologists make life more difficult for ourselves and should actually give things new names, rather than appropriating terms from outside the industry?

The first 90 days of the Chief Digital Officer

The first ninety days in any job are important. But in such a new and exciting industry as online & digital, the first 3 months in the role of Chief Digital Officer are key.

Here are my thoughts on what should be the main areas to focus of the CDO during this period:

1. Understand the overall business strategy
   Any digital strategy created must be completely aligned to what the business is planning (Commercial aims,  new products, marketing, etc.)
2. Learn the culture
   Every organisation has a "way of doing things" and seeing itself. This doesn't have to perpetuate, but it is good to know what sort of people your peers and team around you do and think. Most important is the appetite for change... which can either be a critical success factor or a big nail in the coffin of a lot of the most forward-thinking digital plans.
3. Set a benchmark
   Recognize which of your competitors (if any) are doing innovative things, or just doing the same stuff but better! 
4. Identify your stakeholders and make friends
   From marketing and customer insight through to IT and Operations... if you are going to be an agent for inevitable change, you will need to build allies first.
5. Research your customers
   It's no good setting yourself up to digitize everything if that's not the correct way forward. And it's no good rolling out smartphone apps if all your potential business is using tablets. You don't have to know everything about every one of them, but being able to classify and segment them into target audiences will help you create the most relevant products and experience for them.
6. Build your vision
   Create an idea of what success looks like. What is the end game of all this change and how does it help the user and company? (Tip: Then give this vision to your strongest critic and ask them for feedback - this will iron out a lot of the wrinkles)
7. Create the roadmap
   Draw up and digital roadmap of short and longer-term projects & tactical changes that move the organisation forward towards your vision. 
8. Justify investment
   Where necessary develop businesses cases that explore the investment required to realise the roadmap.
9. Deliver something quickly
   Nobody is realistically going to wait for you to see out your initial 3 months without some business improvement. This shouldn't be too difficult for any CDO new to the role, as there are always quick wins to be had
10. Have fun

Have I missed anything?

Is eCommerce a sector?

Every so often the same debate crops up online. "Is eCommerce a sector?" is generally the sort of question that kick-starts an animated discussion. It then typically ends up changing into a rant or argument about the progress / maturity / understanding of both agencies and clients in the eCommerce space.

My own opinion is that eCommerce is not a sector but a discipline that crosses the different established sectors of technology, retail and online / digital.

What's the difference in these two definitions? Well for me, a sector is more defined by the size and scope of the market rather than the actual work done. For example... if you compare Information Technology (a sector IMHO) with eCommerce (a discipline) then obviously IT is much broader in its range. There is also a lot more people and skill-sets contained within it. eCommerce, although using a fair amount of technology skills (amongst others), doesn't cover anything like the scope that IT does.

Personally I'm happy that eCommerce as a discipline straddles the sectors of online and digital marketing and delivery, retail and consumer shopping as well as technology and its assorted areas. It adds to the mix of projects you can find and the different people you can work with.

What role does your Chief Digital Officer have?

At the beginning of this 2012 I pulled together a post on the emerging role of the Chief Digital Officer (CDO).

Over the last few months I've been considering this role more and now think that this is a job that will become more commonplace in the future. And it would seem that I'm not alone in thinking this, with executive recruitment company Russell Reynolds now stating that

The spike in demand for Chief Digital Officers has been felt globally. In Europe, the number of search requests for this role has risen by almost a third in the last 24 months

So what should the Chief Digital Officer should be responsible for in a major organisation?

Here's my suggestions:

• Having a seat on the board that champions the implementation / growth / adoption of digital technologies & practices, whilst contributing to the overall business strategy
• Online best-practice guidance and mentoring for all executive level staff
• Owning the company's digital strategy (including the digital roadmap of future features and functionality)
• Managing the implementation and management of online services (where there's no dedicated business owner)
• Ensuring the Digital Strategy aligns with overall IT, operational and product / commercial roadmaps
• Overseeing the overall digital user experience (e.g. every online touch point)

The Chief Digital Officer should also have the following experience:

- Experience of working within a blue chip organisation on a global scale (e.g. FMCG, Manufacturing, Online, Retail, etc.)

- Knowledge of Digital Marketing (from search engine marketing through to complex attribution)
- eCommerce best practice (conversion optimisation, merchandising, pricing and fulfillment) 

- A sound grounding in technical architectural and operational standards
- A history of large project / programme delivery

The Service Orientated Architect

With the innovation of service orientated architecture last decade (a set of principles and frameworks for designing and developing software around the re-use of back-end web services) complex web properties  became easier to develop and maintain. Key functionality was separated out and structured along business-focused processes, then integrated back together when required.

But do you ever get the feeling when working with digital technology (and therefore the technologists that wield the magical power to understand and work with it) that your business needs and issues are a mere distraction from their principle aims?

Yup, you're not alone.

It's not uncommon for a lot of Information Technology people, regardless of their level, to consider "the business" as an annoyance or actually having requirements counter to their technological aims.

Perhaps IT people need to be more service-orientated too? Structured and aligned to wheat the business needs, then integrated with their customers.