Archive for IT Enabled Change

Bryan Oak | 5 March 2013
No comments

The journey starts with a purpose and a direction

The journey to the moon started with a vision

In the last few months, I’ve spoken to a number of clients who are struggling to deliver their portfolio of business and IT change projects efficiently and effectively.

Several have started to look for a “Portfolio Manager or Director”. The role descriptions tend to combine implementation of project and programme management standards, referencing Prince2 and MSP and quality assurance; ability to manage senior stakeholders, including those that own or are accountable for the very success of these individual initiatives.

They perceive the problem as being the domain of the project manager or project sponsor, which in part it might be.  However, when asked to describe the changes that they are seeking to make these are either vague or couched in terms of needing to implement particular IT systems.  On too few occasions is the intention of the change described in compelling terms or with a vivid description of the value the business will derive from the range of initiatives that are planned or in progress.

To me there seems to be a number of steps for achieving meaningful and sustainable change, and it starts with knowing what you want to achieve and following a logical path to describing the journey that will be required:

  • Define the strategic objectives that the change is going to address
  • Describe the future mode of operation that will deliver those objectives
  • Assess the gaps to be closed; the improvements to be made to realise that future target operating model
  • Distil the conclusions and prioritise
  • Define an initial roadmap and the options to be evaluated
  • “Finally”, produce the proposed implementation roadmap

I say “finally” but in reality that’s really just the start.  At this stage all you have done is “define” the changes required. You probably haven’t changed anything yet, but at least you now know what you need to change and for what purpose.  You can describe the changes in terms that provide your organisation and stakeholders with a rationalisation and justification for change; a clear statement of intention and direction, and a pathway to delivering the business outcomes that individually and collectively will help you to navigate from where you are today to where you want to be in the future.

It’s unlikely that any organisation, charting their roadmap will consider making the journey in one big step.  On the way to the moon, the USA and the World needed to develop better rocket and engine technology; put satellites into orbit for communications and scientific experiment; to develop and test out equipment and life support systems, and to invent new materials that could withstand temperatures and pressures not previously contemplated.

The journey to the moon, for the public at least, started with arguably one of the most evocative speeches and vision statements of our time:

“…. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too… “

John F. Kennedy
September 12th 1962

Defining your implementation roadmap should start with a vision of what you want to achieve; the direction you want to take and the business outcomes that need to be delivered along the way.

It sounds corny and a bit of a cliché, but a compelling vision statement is not a luxury and must not be some vague, anodyne statement. It needs to be a specific about what is to be delivered and when. It should be supported by statements that reflect an honest portrayal and justification of “why?” “the thing” is to be done, and a depiction of what will or might be different in the future – with and without the changes; the challenges that will be faced, and the budgets and resources required.  After all do you think a man would have landed on the moon on July 20th 1969 if Kennedy had not committed the funds and the nations best resources to the endeavour?

So, as you embark on the next instalment or step on the journey of business change, be sure to understand and define the context for the change, its purpose, objectives and alignment to the longer-term aims of your organisation.  Create that compelling vision of your intention, one that describes what’s in it for you, your employees and the wider business environment.

Category: Enterprise Business Architecture, IT Enabled Change, Leadership, Programme Management, Project Management, Strategic alignment | Tags: , , ,
Bryan Oak | 1 February 2012
2 comments

Please implement my SAP/ERP system ASAP

Unravel complexity

 

 

 

 

 

 

 

 

If you read articles and blog posts on enterprise software projects, it won’t be long before you see tales of blown budgets; slipped schedules; lack of realised benefits and even litigation.  Too often this class of project is the victim of poor delivery and, because of the costs involved, readily attracts poor press.  Regardless of whether these projects include software suites from SAP, Oracle, Infor or any other vendor, they are substantial and tricky undertakings for any organization.

In a recent pre-cursor to their now published 2012 ERP report, Panorama Consulting (panorama-consulting.com) cite that nearly half (44-percent) of all ERP implementations fail to deliver at least half of their expected business benefits; 54% (down from 61% in 2011’s survey) run over schedule and over budget by 25% on average.  It’s true that the occurrence of failure is publicised more often in the press than success, but even so, why does the occurrence of failure seem so prevalent?

Plenty of time and blog-space is devoted to the topic of critical success factors (CSF) for successful projects.  Usually the list will include leadership, data, scope control, requirements management and managing the impact of change on the organisation – you can add your own 6th, 7th or even 8th CSF!  This might be vision or governance or testing – all very sensible, easy to understand and advice that has been repeated numerous times over the past decade and half that I have been involved in these programmes.

So surely, the majority of folks are not ignoring or neglecting this sage advice?  And hopefully the World is not completely stocked with incompetent project managers and leaders.

There has been a steady stream of articles, discussions and blog posts, including from Bill Wood at R3Now.com, highlighting that the lack of using a strong methodology is a contributory factor to project failure, and that project managers (in Bill’s case he was highlighting SAP Project Managers specifically) are ignoring the assets that vendor methods, such as ASAP, offer, in favour of developing their own accelerators because they either do not know these methods or “have a financial motive not to” use ASAP.  Whatever the motivation, the consequential lack of adherence to a rigorous method is contributing to failure and missed expectations.

To test the “state of the nation” @LIBACAS conducted a poll across several, relevant LinkedIn Groups to ascertain the extent to which SAP Project Managers have been formally trained and are keeping up to date with the ASAP method, by way of an example for vendor prescribed implementation methods.   The results are somewhat disappointing, but probably not all that surprising.

Out of a sample of 29 project managers who responded:

  • Only 10% had undertaken formal ASAP training within the last year.
  • For 31% it has been more than five years since they were formally trained in ASAP, so they may not be aware of the latest additions or how to navigate the method roadmap, access its repository and run an SAP project using Solution Manager – SAP’s recommended way of using the method to its fullest.
  • 17% have only ever been trained in their employers’ methods, which align, incorporate or, at best, pay homage to ASAP.  Again, potentially missing out all the available support and aids that the vendor method could provide.  And, perhaps most revealing,
  • 42% have learned everything they know about ASAP “on the job”.

Now, it’s probably fair to assume that many project managers will have had training in a formal project management standard – PMI or Prince2, but these do not offer the same extent of guidance and support for enterprise software implementation projects that vendor specific methods will.  So, it is highly likely that project managers are missing out on useful tools, disciplines and accelerators due to a lack of formal training.  That’s certainly not going to help the situation, but is method the root cause of a high percentage of project failures?

Ken Koch, from BRMOnline.com – responded in a recent discussion on the topic “My experience has taught me that it isn’t the methodology for an ERP system [that gives success] it is the company’s ability to adapt and adopt.”

Again the “adaption” theme has been often repeated and leads to the “we will stick to vanilla” and “change the process not the package” mantras of every client Steering Board.  However, this is easier said than done, with 53% of Panorama Consulting’s respondents admitting to “some”, “significant” or “extreme” amounts of customization in their projects.  In my experience, at least 20%-25% of a project’s budget will be consumed with development effort, as opposed to configuration, as the business changes the behavior of the software to fit their processes, rather than the other way around.

The “adopt” conundrum – getting the business to change to fit the application – is obviously the territory of organizational change management, communications and training.  Again an understandable feature of all lessons learned reports; CSFs for successful projects and high on the list of every ERP related consultant worth their salt.  While many businesses do underestimate the difficulty of getting their organisations to change, to understand, adopt and accept the new processes, practices and applications, most do at least plan for activities in this arena as part of their overall project.  So, is a failure to address business change really the main factor in project failure?

Or perhaps all of the above are guilty parties, accomplices to the crime, and the problem that needs to be managed is the inherent complexity of these projects, the breadth of scope, the business and IT dimensions, the impact on people, data, processes and infrastructure. Is complexity the root cause or at least the main driver of failure?

The breadth of their potential capabilities, their tightly integrated nature and the anticipated benefits of deploying commercial enterprise software suites often leads companies to “plan big”.  Wanting to implement to the fullest extent, there is a tendency for projects to bite off a lot (too much?) in one go.  Review the scope of most of ERP-enabled business change projects and it is likely to encompass a large proportion of an enterprise’s core business processes. That’s a lot of activities, functions, transactions and people to consider, even in a small business.

It’s true that the native integration; the ability to replace whole swathes of legacy applications, and to deliver standard, end-to-end business processes, is a powerful lure for any business.  Keeping the scope intact and delivering the new processes and applications in a “big bang” to the business, promises to keep technical implementation complexity down and more quickly realise improvements in business efficiency.

According to the Panorama Consulting survey, 57% of organisations that responded took a “big bang” approach across the whole company, or phased total process scope by geography or business unit.  On the flip-side, the larger the scope, the more resource is required from the organization to support the implementation; the more business change needs to be absorbed by the business and the more integration and coordination is required within the project to keep everything joined up and inter-dependencies under control.

Review the proposals from the vendors and their consulting/SI partners and you could be led to thinking that the bigger the scope the better from an integration and implementation perspective; that the risks are entirely manageable, and you can still get everything you want Mr/Ms Client within your budget (aka “the selling price”).

As Dave Heafield, a seasoned SAP HR and Payroll Programme Manager commented in response to our poll – “my experience has shown that if clients take [the vendor’s] sales pitch with a huge pinch of salt and as a balance take advice from experienced PMs, then they’d allow longer for the transformation and agree up front it’s going to cost them more than [the vendor or SI] told them. They can still justify it with a sound business case but they go in with eyes wide open and avoid the “it’s late and costing more than planned” discussions later when they’ve already spent too much to stop.”

So, to conclude, after 15-20 years of ERP implementations, the rate at which projects fail, judged in terms of time, cost and benefits realisation, is still too high.  Any list of CSFs is probably right. All those areas need to be addressed and factored into any project from the outset, but the top three things that will make or break a project are:

Experienced Project Leadership

Experienced leadership will obviously help. Make sure your programme and project management has proven experience from a business and project delivery perspective.  They need to be able to implement a formal and disciplined project methodology; know about and be able to access current, best practice tools and accelerators.  Above all they need to convey the method, expected standards and the use of tools to the team, then stick to the disciplines.

Realistic Expectations

C-level executives want results, the quicker the better.  They will (usually) rationally expect a fair cost, proportional to the expect return, with minimised risk and disruption.  Above all, they do not want surprises.  Heed the advice and data points in the public domain.  Challenge the basis for estimations; identify the areas of uncertainty and the gaps from today’s way of working or organisation.  Assess risks and mitigations, and budget time and costs accordingly.  Invest in the planning and preparation stage, but do not expect to plan the end-to-end programme in detail.  Build in contingency, but work to an aggressively realistic schedule and manage expectations of those that “just want the thing to be implemented”.

Tackle Complexity

Above all, any programme needs to address complexity upfront. The scope and implementation plan for your ERP project needs to be divided into manageable chunks – balancing scope, costs, time, risk and benefits, of both technical and business delivery.  Fundamentally, smaller independent or loosely coupled projects will be easier to manage and have a better chance of success than large, complex and overblown, multi-multi-million dollar/pound programmes.  Use Enterprise Architecture approaches to scope you projects and plan out your programme roadmap to deliver in releases and phases.

If it’s planned to take 18 months, two years or longer to deliver the project, whether your actually successful or not will be a moot point, the business will have moved on by the time that the shiny new ERP system hits the streets.

Delivering agreed capabilities, over a series of successful 6-9 or at a push 12 month projects, will be received far better than returning to the Steering Board to ask for a 6 month extension and an additional 30% to the budget, assuming that you still have a job in the first place!

Category: Business Processes, Enterprise Business Architecture, ERP, IT Enabled Change, Leadership, Programme Management, Project Management, SAP |
Bryan Oak | 11 January 2012
No comments

Business process mapping is boring!

Process mapping is boring

Open any book on business change, process improvement, enterprise architecture or systems implementation methods and one activity is certain to feature early on in the recommended approach – process mapping.  Documenting a graphical representation of the processes, activities and tasks that the organisation performs to execute its business.  Whether that be the current or future state, capturing process descriptions is seen as an essential task for any business improvement, change or systems project.  However, for the participants, those that are being asked to give up their intimate knowledge of the processes they work with, it can still be a hard sell.

Too often the purpose of capturing processes is positioned as, or perceived as, the production of process diagrams – the mapping activity has a tendency to become self-justifying.  The amount of time and level of detail that is required to capture processes, gathering the underlying data and information, seen as boring, a drain on resources, even an unnecessary task conducted to educate the consultants and sometimes even a personal threat.

So why is process mapping identified as being so important? What can you gain by documenting processes?

The potential value of and reason for process mapping could include:

  • Analysis and problem solving – used to uncover issues, bottle-necks and come up with ideas for improvement
  • Process improvement – identify non-value add activities to improve process effectiveness, efficiency, decrease the opportunity for error or reduce costs by eliminating non-value add activities
  • To elicit requirements – the discussion and narrative that occurs when you map processes is used to frame and elaborate business requirements
  • Identifying interfaces and hand-offs – useful in defining service agreements and contracts between organisational entities or to specify system to system interfaces
  • Alignment of roles and responsibilities – which can be used to target training and define security requirements
  • Explaining downstream consequences – by exposing participants to the end-to-end process, the consequence of an error generated upstream can be explained more easily
  • Communication and training tools – the diagrams can be used to provide context for education and training.  This is especially effective if communicated by somebody who was involved in their generation, to provide the “colour commentary”
  • Hand over documentation – in outsourced arrangements with an external service provider, process documentation should enable a better understanding of business operations, process activities and systems configuration.  This is one of the purposes that may manifest resistance from participants who feel naturally threatened by such business arrangements
  • Alignment of performance metrics – both for process level and individual personal performance measurement, process maps enable measures to be defined and positioned at the appropriate part of the process to create leading and lagging indicators
  • Support for compliance and control processes – using process documentation to provide evidence of operating standards and quality controls to achieve industry or regulatory compliance and certification

The capturing of processes creates a shared understanding and a common language for the organisation.  It makes end-to-end process flows and interactions visible.  Depending upon how they are used, process maps provide the basis for improvement and change, as well as a framework for day-to-day management and controls.

There is as much, if not more value in the process of generating the documentation and maps, as there is in the end product diagrams themselves, but the mapping activity needs to have a clear set of objectives and shared purpose.

The approach and techniques used in process mapping should be easy to understand and supporting tools intuitive; complicated and abstract techniques and tools will only engender resistance to the task.  Approaches should encourage or enable an “outside in” or customer perspective of how things work or could work – a process that does not deliver what its customers need is not effective; a process that is inefficient does not give the participants/actors what they need either; a requirement that is not captured from the user’s perspective will not deliver the experience that is required from a successful system.

The diagrams and documents need to be in a form that is easily understood, communicable and accessible.  They need to have the ability to stand-alone with limited explanation, but must retain and be able to convey the information that underlies the process map, so that those not involved in their creation can still extract value from them.  The burden of and commitment to maintenance needs to be assessed upfront, you do not want to be repeating the exercise in 3 years time, because the information is out of date and a different set of participants do not feel any emotional attachment to the original documentation.

View process mapping as a means to an end, not an end in its own right.  Be clear on the purpose and objectives of process analysis and mapping. Explain to contributors the expected value and handle any change management concerns up front; provide context for the activity – is it to capture today’s processes in order to … or to capture a common perspective of the “to-be”, providing a target description of the future state that the organisation wants to be at/in? Do we want the ability to map the gap/changes that will be required to move from the “as-is” to the “to-be”? Are we trying to define requirements for new processes and systems? How will the documentation be used afterwards?

So, when somebody says “we need to map our processes” don’t be afraid to ask “why?”.  It is certainly an important stream of work in any project.  If you understand the objectives and purpose, then chances are there will be less resistance and better quality as a result.

What’s your perspective? Do you have any hints or tips for improving the effectiveness of process mapping activities?

Category: Business Processes, Enterprise Business Architecture, IT Enabled Change | Tags: , , , , ,
Bryan Oak | 24 December 2011
No comments

Change – it’s written in the clouds

Cloud offers metaphor for change leadership

Change leadership inspiration from natural phenomena

In the week before Christmas 2011, the good people of West Yorkshire, England were treated to the rare sight of spectacular cloud formations – Altocumulus Lenticularis.

I have also had the fortune to see this type of cloud, in all its dramatic beauty, while walking in the Riff Mountains, Morocco near Chefchaouen. The vivid image of the cloud remains imprinted on my memory and led me to read a bit more about this cloud type and its formation. The conditions and formation process for these lens-shaped clouds, often mistaken for UFOs, actually provides an analogy for leading change – bear with me on this!

Referring to “Cloud Spotting” by Gavin Pretor-Pinney amongst other sources, Altocumulus Lenticularis are described as mid-level formations composed of droplets or ice crystals that form patches or rounded clumps of almond/lens-shaped clouds. Usually above the influence of localised air currents and thermals, lenticularis form when air passes over a large obstacle and cools as it is forced upwards. They are seen hovering close to hills. In the same way that a fast-moving stream flowing over a large rock can result in a stationary wave shape downstream, standing crests develop in the lee of the hill’s or mountain’s summit . As the air rises, it expands and cools, causing the moisture in the air to condense into clouds at the crests of the stationary wave.

Dramatic and beautiful, they look solid, with a smooth silky surface, but are actually composed of a large number of very small droplets. Although seeming to stand still, air is actually blowing through the cloud, forming droplets at the front which then pass through with the airstream and evaporate as they come down the back of the wave crest. When the airflow is at a constant speed, the point at which the droplets form and evaporate is fixed, creating the spectacular lens shape and the cloud appears stationary. In reality it is in a constant state of flux.

So, how does all of this relate to leading change?

Think about it -

  • Lenticularis form in the lee of major obstacles.
  • The clouds appear solid and stationary; presenting a consistent and stable image despite the flow and turbulence.
  • Unperturbed by “the influence of localised currents”, this single “structure” is actually an ordering of a large number of small components brought together, all be it temporarily, by a steady flow of activity.
  • They are often mistaken for UFOs, something far more strange, dramatic and inexplicable; to some scary, to others curiously exciting.
  • However, they are actually subject to and caused by predictable processes and laws of physics and nature, processes that can probably only be explained by a relatively small community; easily understood by a few more; viewed by most as a mere spectacle, passing curiosity or completely overlooked.

Lenticularis only form in specific conditions and close to specific landforms. If the conditions and landscape are different – warm airstream; vast, flat plains or expanses of cool water; air currents of differing speeds or directions, then turbulence in the cloud layer can take on a very different form known as a Kelvin–Helmholtz instability. Recently seen in Birmingham, Alabama, fast-moving, lighter density clouds slide on top of slower, thicker layers of cloud, dragging out the surface and making the cloud resemble a wave rolling along the top of the water. Again, it looks spectacular but more like a tsunami in the air – and we all know how dangerous they can be.

 

Read more: http://www.bbc.co.uk/news/science-environment-16309120

Read more: http://www.dailymail.co.uk/news/article-2076755/Giant-tsunami-shaped-clouds-Alabama-Incredible-wave-clouds.html#ixzz1hQnO0ytO

Category: Inspired by nature, IT Enabled Change, Leadership | Tags: , ,
Bryan Oak | 6 December 2011
2 comments

What can business change projects learn from the film industry?

Directing your own successful project

Learning from filmmaking

We’ve all heard of the successes and too often the failures of business change programmes, especially those that involve IT systems. The failure to achieve deadlines, deliver to budget or realise the expected benefits.  Nobody will deny that implementing change can be difficult, but need it be as fraught as it seems to be?  In thinking about this, looking for inspiration and innovative ideas as a change project leader, I have often been drawn to using the film industry for parallels and was reminded of this today, reading an article on Martin Scorsese in Fast Company (The Vision Thing).

So how are the types of projects and business change initiatives that we get involved in similar to the world of film? All be it from a layperson’s perspective, the following outlines some parallels which, I think, project leadership could draw inspiration, including:

  • Vision and objectives
  • Planning and preparation
  • Risk and change management
  • Prototyping
  • Project plan and budget management
  • Team management
  • Stakeholder management

Let’s start with the commissioning process – you need to have a “killer pitch” to get your investors.  Whether you’re the director with a pet project or writer with a story itching to be made, you need to get production houses or other potential investors willing to commit funds and resources to the project.  Without a compelling, initial pitch that grabs attention, there is no project.  Within our world of IT enabled change programmes, this is equivalent to the initial vision, high-level statement of objectives and business case; the answer to the “why should we fund this?” question.  Unless you are a “known name” like Scorsese, this needs to be the much vaunted elevator pitch – you only have a few minutes if not seconds to grab their attention, so it better be good, otherwise your sponsors and money-folk will move onto something more pressing.

So, let’s say, you now have approval to proceed, what do you do next?  Bring in the cast and crew and get shooting right?  Wrong, you need to do two things, visioning and planning, with visioning being most critical.  In film making, its the director who is key to creating a vision of what the film will look like; how the story will be interpreted; the types of characters the actors will need to portray and the process to be followed – in effect the principles by which the film will be made.  They will engage a few trusted collaborators to develop richer detail of the vision; to decide on cinematic style, sound, lighting and cinematography; to visualise the scenes and locations; form an idea of the key actors and the crew members that they want around them; identifying candidates who are suited or capable of doing what is required for this production.  This all takes money, so we need to have outline shooting plans and budgets developed.

Probably during this process the director should check back with the producers, making sure that they are “happy” with the vision and direction that is forming and giving them more information to secure final production budgets.  I say “probably” and “should” because in the creative process of making a film (or delivering a project) there is a balance to be had between keeping your senior stakeholders on-board; maintaining the vision; heeding advice and maintaining engagement, but not being overly influenced by individual opinions and pressure to do it “their way”, e.g. hiring particular actors who aren’t right for the film.

Now you are ready to start engaging cast and crew.  Through auditions and interviews, referrals and approaches, the producers and director put together the right team for the job, recognising the specialised roles that are required and the unique skills or styles that will fit with this particular production.

A filmmaker doesn’t cast or hire just anybody, they try to get the right people for the role, be it acting or production.  They’re picky and demanding; they use references and past productions to find the people for this specific production.  Like most project managers, they often go to the people that they know, have worked with before and can trust to do a great job.

The process of forming the cast and crew team has two or even three correlations in the world of IT enabled business change programmes – the key business actors, the internal members of the crew and the external crewmembers coming from the freelance community, consulting or systems integration partners.  The selection of each is important – the business team members (the actors) need to be perceived in the right way by the wider business community (the audience); the internal crew members need to have the requisite skills, or at least the ability to learn quickly, and the external crew members the skills, existing credentials and past performance references.  What is important in all cases are the individuals, not the organisation that they come from, but the individuals themselves – their experience, their skills and aptitude, flexibility and ability to respond to changes, resolve issues and pre-empt risks.

You’ve pulled together your key cast and crewmembers, now we can move onto shooting, right?  Not yet, each aspect of the vision needs to be communicated and broken down to the next level of detail; everyone needs to know what the film project is about; how it will look in the end; how the story develops and what is expected of them and their teams.  They need to understand and share the vision and objectives for the project, and plan their activities to deliver against their role.

This will take place in a number of ways – storyboards, walkthroughs, and briefings.  The story is broken down into scenes, often using actual physical drawings/sketches of each scene, as described in this article on the recent Planet of the Apes prequel, (again from FastCompany.com) about storyboard artist, Tim Burgard (Storyboarding The Apes).  A form of early prototyping, storyboards are another way for director and storytellers to flesh out the vision for all to share and engage with.  The actors will often conduct walkthroughs and script reviews to get the dialogue and acting directions defined and agreed before they set foot on the set.  The set makers, special effects and costume designers will get a better feel for what their creations need to achieve, and the location scouts will have a much better idea of the locations that they need to search out for shooting particular scenes that take place outside of the studio.

Armed with this information, the actors and crew can set about preparing, rehearsing, detailed planning and scheduling.  All the time the production team control budgets, schedules and keep their stakeholders informed and engaged, to keep the money rolling in to support the production shoot.

As for any project, risk, issue and change management are key activities that need to be started during preparation and continually managed.  Even in the world of films with human actors, things will happen or scenes will not work out as envisaged, requiring changes and adjustments to be made.  In wildlife filmmaking where the “actors” can be less predictable or natural events intervene – rain falling in the wrong place or at the wrong time for example – its important to plan for risks and alternative scenarios.  If the wildebeest on the Serengeti decide to cross the river two miles upstream from where you’ve set up for that big migration shoot or that once in a lifetime opportunity to film flowers in the middle of a desert, and the rains don’t come, you better have a plan ‘b’ and even a plan ‘c’ that can easily be put into action, without blowing the budget or the schedule.

As you start to film each scene, you have a detailed plan of execution; a clear idea of the part of the story to be told; the set directions; the lighting requirements; the lines to be spoken; the behavior to be captured; the time allocated for the shoot and a clear vision of what success will look like at each stage.  With the benefit of “rushes” the director and crew can get a quick, early look at the results – in effect another form of prototyping.

After principal photography is concluded, it is traditional to hold a wrap party; a party organized for the cast and crew of a film to celebrate the end of principal photography. Aside from promotion by the “stars” when the film is released, this usually marks the end of the actors’ collaboration (save from possible dubbing or pick-ups) on the film.

Post-production and the editing process is probably the major departure between our projects and most films.  The director and editor get to review, cut and stitch together the individual shots; play with the sound and add special effects.  For project leaders, there is usually only one completed version each scene that enables you to move on to the next stage, not quite a single take but close, so preparation and a shared vision of what is to be achieved at each stage is of the utmost importance.

Finally, although only really used in mass-appeal cinema, there is the filmmakers’ equivalent of user acceptance testing – pre-screening different edits of the film to audience test panels to gauge reaction, enabling final fixes and changes to be made before rolling the film out for distribution.

In summary then,

  • Vision and objectives – the Director needs to have a vision and communicate a compelling pitch, to get stakeholders on-board and to keep cast and crew (the project team) on the same page
  • Planning and preparation – systematic development of detail to flesh out the objectives and purpose of each scene and the plans, schedules and activities required for each part of the production
  • Risk and change management – preparation for the unexpected and adjustment to change when things don’t work out as expected
  • Prototyping – gaining early visibility through storyboards, walkthroughs, rushes and sometimes audience testing to ensure that the finished product will hit the mark
  • Project plan and budget management  – keeping on top of the project schedule and costs for each element, as well as the overall project and budgets
  • Team management – keeping the cast and crew engaged, motivated and heading in the right direction to achieve the vision of the finished production
  • Stakeholder management – keeping producers, studios and commissioning editors on-board and informed
Category: Innovation, IT Enabled Change, Leadership, Programme Management, Project Management, Uncategorized | Tags: , , , , , ,
Bryan Oak | 23 October 2011
No comments

Leadership and Innovation in Business Architecture

Welcome to the LIBA Consulting and Advisory Services (LIBACAS) blog page.

Over the coming weeks and months, we will discuss a range of topics related to IT Enabled Change and the part that Enterprise Business Architecture has in defining, planning and executing successful change projects or programmes. Focusing on the themes of Leadership and Innovation, we will be exploring what it takes to deliver real business value and sustainable business change enabled by enterprise applications and technology.

Reflecting on our consultants’ experiences and those of associated experts, we will look at the lessons to be learned from the successful and not so successful, to distill out the factors that contribute to successful change programmes.

By examining “disruptive” technologies and concepts, such as business process management (BPM), mobility, social media, “big data” and cloud, we will be discussing the impact on and opportunities created for companies planning their future operating model, business architecture and to-be business processes.

Too often we hear about projects and change initiatives going awry, with significant time and cost over runs, and failure to deliver the expect benefits.  You read about the benefits that enterprise applications suites offer, only to then read that they lack flexibility, inhibit agility and stifle innovation.  Through this blog, we will be looking to share our own perspectives, share insights from across the Web and explore approaches/techniques that just might make a difference to your next IT enabled change project.

We hope you’ll share the posts, as well as join us and contribute to the debate and discussion – just use the Comments button at the top of this post.

 

Category: Enterprise Business Architecture, Innovation, Introduction, IT Enabled Change, Leadership, Programme Management |