Some thoughts on Business Transformation efforts

First of all I think the term "Business Transformation" is somewhat overused therefore let's first clarify what Business Transformation means.

Definition from the business directory (see this link) : In an organizational context, a process of profound and radical change that orients an organization in a new direction and takes it to an entirely different level of effectiveness. Unlike 'turnaround' (which implies incremental progress on the same plane) transformation implies a basic change of character and little or no resemblance with the past configuration or structure.

Who is responsible to drive the Business Transformation?
There are different thoughts on this which range from CEO, CMO to CIO. You can search the web for various points of view. In any case it should be very clear at the beginning of a business transformation effort who owns it. Whoever it is in your company they should actively support it.

Define in what environment a business transformation takes place.

• In case of a growing business
• Most likely the old processes and tools are no longer sufficient to deal with the challenges of a growing business. See this link to explore that in more detail
• In case of a mature business (and a growing business as well)
• Check this excellent article from McKinsey
• Key Points are
• Set clear objectives
• provide strong leadership support from the top
• setup a clear organization structure for the transformation
• maintain energy and involvement throughout organization 

Who (System Integrator) can help you with the Business Transformation?

• Check this link to get a general idea about the challenges with System Integrators
• Make sure that not only cost dictates what you plan to do! You will work with this team for a considerable time and hence you need to be certain that there is a fit with your companies culture.
• Do you want to work with only one system integrator (SI) or consulting company or do you want to involve multiple SI/consulting companies?

Here are some signs, from my experience, that a business transformation effort has serious challenges

• Large parts of the organization don't understand really what the business transformation effort is about or what it tries to achieve
• Leadership does not actively and frequently support the business transformation effort (an occasional email or video on the intranet is NOT sufficient)
• It takes too long to see any progress (e.g. "PowerPoint transformations" can go on for a year or longer before any real progress can be shown to end users) --> this might remind you of a "Waterfall" Project

Here are some key to-dos, from my experience, that I would propose to any business transformation effort

• Ensure the whole organization understands WHY the business transformation is needed. The majority of company employees should clearly understand and support this effort (see also John P. Kotter "Leading Change" for basic Change Management guidance). This means COMMUNICATE, COMMUNICATE, COMMUNICATE !!! --> everyone should be able to recite the elevator pitch for this transformation.
• Have active, visible and regular Senior Leadership support! (e.g. CEO, CMO, CIO)
• Assign clear Roles & Responsibilities at the beginning. This will require considerable time but is well worth the effort! Instead of stepping on each others toes teams can collaborate instead
• Break the business transformation effort into "digestible pieces"! e.g. a new ERP implementation can be overwhelming and should be broken up into smaller pieces so that the impacted stakeholders better understand what is changing and why it is changing (and hence increase the likelihood of a successful project/program)
• Have 3-6 month release cycles for the business transformation changes. That way it's easier to see and buy into the changes
• Have dedicated Change Management resources assigned to ensure impacted teams understand early on, how they will be impacted (and what the benefit is)
• Actively support team behavior between Business and IT Teams ! They are on the same team and should behave that way! Make sure this actually happens.
• Measure where the transformation effort is compared to the final objective and COMMUNICATE this regularly (e.g. quarterly) to all stakeholders 
• Do NOT build "exclusive groups" of any kind - this is a team effort and needs to be treated as such!

Agile Project Management with SCRUM (based on the book from Ken Schwaber) - a cheat sheet

Several years back I read the book "Agile Project Management" by Ken Schwaber. From my point of view this is a good introductory book to learn the basics of Agile Project Management with SCRUM. I had created a kind of cheat sheet at the time that I share below so that you can use it to become familiar with the basic SCRUM ideas quickly.

First here is the link to Ken Schwaber's book.

SCRUM Roles - check this link to learn more about these roles (scroll down until you see "roles")

1. Scrum Master
2. Product Owner
3. Team

Phases

1. Vision (similar to Project Charter)
2. Create Product Backlog (prioritized) --> check this link to see what a Product Backlog is
• Functional requirements
• Non-functional requirements (QA)
3. Sprint Planning Meeting (1 day) --> check this link to see what a Sprint Planning Meeting is
• Select Product Backlog (4h)
• Prepare Sprint Backlog (4h) --> check this link to see what a Sprint Backlog is
4. Sprint (30 days) --> objective: create shippable code!
• Includes Analyze, Design, Code, Test, Documentation
• Daily Scrum (15min) --> Product Backlog to be updated by Team
• What have you done since the last SCRUM?
• What will you do between now and the next SCRUM?
• What impedes you from performing your work effectively?
5. Report
• Product Backlog at the start of the sprint
• Product Backlog at the end of the sprint
• Changes Report (Difference between the two previous Reports)
• Product Backlog Burndown Chart (measures amount of remaining backlog work)
6. Sprint Review Meeting (4h) --> check this link to see what a Sprint Review Meeting is
• Team presents to Product Owners + stakeholders functionality that goes into production!
7. Sprint Retrospective Meeting (3h) --> check this link to see what a Sprint Retrospective is
• Attendees: Team, ScrumMaster, Product Owner-optional
• What went well during the last sprint?
• What could be improved?

For multi-site projects see this link for SCRUM of SCRUMS.

Additional resources:

• http://www.controlchaos.com                             Ken Schwaber Website
• http://www.mountaingoatsoftware.com/scrum   Mike Cohn Website
• http://www.scrumalliance.org
• http://www.agilealliance.org
• http://www.youtube.com/watch?v=IyNPeTn8fpo (1 hour introduction of SCRUM from Ken Schwaber to Google employees)
• http://www.pmi.org/Certification/New-PMI-Agile-Certification/PMI-Agile-Toolbox.aspx

Idea's for setting up an integration Kick-off meeting after an acquisition

Acquisition Projects are a little different from "normal" projects because one party (the acquiring party) will most likely keep many processes and systems in place while the acquired part will have to adjust their processes and systems.
This is obviously a big change for everyone and needs to be well planned to ensure a successful transition. Below I have put some high level Points together that I consider useful for an acquisition kick-off meeting:

• Setup a Kick-off meeting to clarify scope, objectives and what success looks like
• Example: You might have the following teams from the acquiring and the acquired company: Integration Management Team, Business Team, IT Team and cross functional teams (e.g. Go-to-Market, Quote-to-Cash).  Everyone needs to understand the Roles & Responsibilities clearly!
• Tell Integration participants about the acquired company! e.g. History, Culture, Revenue, number of customers, number of employees, location of customers, company is present in how many countries, any alliances the acquired company has etc. 
• Review/Discuss Integration Strategy  (ensure the impact of this is understood by the acquiring and acquired teams). 
• The following points should be addressed
• Overall Strategy (e.g. Integrate acquired company into Business Unit xyz with minimal disruption within x months)
• Business Model (e.g. apply business model and operating model from acquiring company)
• Organization Changes
• GTM Strategy (e.g. Integration of sales force and reseller channel)
• Partner (e.g. Integration into acquiring company Partner Program)
• Product Integration (e.g. adjust User Interfaces (UI)of acquired companies Software Program to get the same look and feel as the acquiring company)
• Services & Support (e.g. Integrate Customer Support into one team)
• IP Integration (e.g. Intellectual Property transition to acquiring company)
• Operations (e.g. acquired companies product need to be available on acquiring companies systems within x days)
• Business Functions e.g. transition Professional Services from acquired company to acquiring company
• HR e.g. stock options plans for key executives and employees
• Real Estate e.g. consolidation of offices
• IT e.g. Network connectivity
• Finance
• Tax/Legal e.g. company car policy of acquiring company applies
• Review proposed timeline and milestones
• Review communication requirements (internal & external)
• internal: assign contacts to minimize daily operation interruptions for acquired company
• external: designated one communication contact to prevent any confusion
• Review where the Integration Documentation will be stored (e.g. SharePoint)
• Review proposed acquisition project update schedule (and ensure all stakeholders are ok with that.  e.g. all Senior Management stakeholders want to be updated every week, Wednesday)
• Review M&A Playbook (high level review to ensure everyone understands where we are and what we are targeting next)

Take some time to go through this and don't rush it!