I recently worked on a project to migrate from Lotus Notes and Microsoft Office to Google Apps. Google Apps offered tremendous benefits, but it was a big change. Sometimes the success of the change hinges not on the change itself, but how it’s managed and the change management process that is outlined by Google was simple and effective.
Google provides a guide explains how to address user concerns, such as:
It ensures
You’ll find many models for change management. Google use the simple one Get Ready, Communicate and Train.
For a Medium to Large company of 250 or more employees, a standard Google Apps transition is divided into four phases:
Each of the phases includes a project plan that will include Get Ready, Communicate and Train modules.
For more detail please read this document.
Once, as a team, you have decided that you are running in certain direction, then it’s the leader’s job to clear the path, get the obstacles out of the way and make it fast to make decisions.
Another way of saying this is that it’s the leader’s job to create the environment for success and the largest part of this is about clearing barriers to performance out of the way. Find and remove the objections to achieving the objectives.
I deliver Business Growth, by leading a great team
I show them how team success, helps achieve their dreams
The chance to make a difference and to do something good
The chance to build their skills and grow as as they should
The chance to provide, a future for their family
And build this future on merit, success and security
With all the barriers removed and no reason to hide
They will rise to success on the platform I provide
I start with Customer Profile and a Value Proposition,
Then the team to deliver, Customer and Revenue ambitions
Efficient and effective with tools, training and skills addition
We Begin and Establish Growth and later Optimise our position
From Market Entry to Development, it’s the same approach I feel
Better to use experience and process, and not reinvent the wheel
Diagnose the Challenge first, and then onto Solution creation
And then a project plan, for controlled Implementation
Is PRINCE2 still relevant in an agile world? Or like in the fairy-tale, has it lost its relevance and changed into a frog? Well, no… it is still very relevant for two reasons:
PRINCE2 is not the only option when considering a traditional methodology but it is a popular one and one that blends in well with new Agile project methodologies such as the Agile project management framework which is derived from DSDM.
PRINCE2 is a formal, structured approach to project management. It recognises that there are three major levels of activities:
The major focus of PRINCE 2 is in management and direction. Delivery it treats as a black box because it may be internal or external. Prince2 does not dictate how delivery is done but it does state the expected communication and deliverables.
A PRINCE2 project looks like the following:
In fact, the 2009 revision to PRINCE2 reiterated its underlying simplicity by recognising explicitly seven principles:
It doesn’t say anything about how you should build your products.The only things PRINCE2 says about making things is the following:
PRINCE2 can be used to manage the project and Agile methods can be used to deliver the solution. The two methods are entirely complementary; they touch only in the definition of what constitutes a “workpackage” – and they even agree on how big that should be!
A paper on integrating DSDM and PRINCE2 is on the DSDM website. Another option is to use PRINCE2 for direction and use an agile Project management methodology and solution delivery. Agile Project Management is an initiative which extracts the Project Management elements of DSDM Atern and makes them available as Agile Project Management – a certified approach in its own right. This can then be combined with popular Agile solution delivery approaches such as Scrum and XP. This is detailed in this Agile Proect Framework for Scrum document.
In some cases the requirement may be to go completely Agile. This is possible as long as the direction provided is agreed and sufficient for the company leaderhip. Agile Project Management derived from DSDM (Shown in next 2 diagrams) or Disciplined Agile Delivery (Shown in bottom diagram )may be used.
Lou Gerstner of IBM famously said “who says elephants can’t dance?” Can big organisations act in an agile way? Do they have to throw everything (traditional methodologies) out and start again? To be agile do you have to go completely Agile and use all Agile methodologies.? Most companies according to research seem to be adopting a hybrid approach. The term Water-Scrum-Fall has been coined by Forrester to describe waterfall processes at beginning and end and Agile (Scrum) in the middle. It recognizes how many firms blend an approach of writing most requirements up front, using time-boxed sprints to code, and then falling back on traditional big-bang deployments. Sure there are some companies that are fully agile and Agile but there are some that are fully waterfall but can still adapt sufficiently to their environment. Why? Because they have different problems to solve.
Agile methodologies tend to be better in smaller and innovative environments. Waterfall are still best for very large scale project coordination and where features must be delivered at a certain time e.g a datacentre move.
There is no one size fits all. The trick is to apply the right approach in context, according to the needs of business leaders and recognizing the pace that the organization can successfully absorb new ideas and new methods and if they are right for the problem in hand.
Regardless of approach the following parameters will have a large impact on the success or failure of a project. If there is no management sponsorship then a major project will fail. If the business objectives are not clear then it will fail. The amount of information available upfront may dictate approach. Little information upfront may dictate an agile approach…but it will probably also mean that only a little money is approved and that approval will be required after every increment. A company that is dominating its market and is deciding to spend some of its cash pile on entering a new market is in a much different position than a company that is a follower in the market and is trying to deliver a large customer contract.
It is more important to be agile than to be religious about Agile methodologies.
Parameters For Success | ||
Market Position & Maturity | Product | Organisation Culture |
Acceptability of Change | Management Sponsorship | Clear Business Objectives |
Strong Customer Involvement | Optimal Project Complexity | Optimal Project Size |
Team Skills | Team Emotional Maturity | Project Management Expertise |
Tools & Infrastructure | Information availability |
Parameters derived from my own research and experience. Used the Chaos Manifesto 2013 for some input. (There are questions over the details of their research but some of the macro stuff seems ok)
In managing a project to develop and deliver a product the traditional way of delivery are methods such as PRINCE2 (PRojects IN Controlled Environments) which is a widely used project management method that provides all of the essentials for running a successful project. It is sequential in that one task is finished before the next starts and the product is delivered at the end and is managed by a plan. Traditional plan based sequential methods are known as generically as “Waterfall”.
A new way of developing and delivering products is Agile. It is a term commonly associated with software development. The Agile Manifesto was published in 2001, building on work throughout the 1990s, which summarised the core philosophy behind agile development philosophies. This consists of 4 key values and 12 principles.
“We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more”.
Agile started out improving software development but the term Agile has evolved into an umbrella for a group of methodologies that can be used to manage business change projects. Agile delivery teams will develop a project :
It is worth noting that Agile, recently, has had a good press and Waterfall a bit of a poor one. However, both have value and can be utilised depending on the problem to be solved. A methodology does not make up for bad management or unreasonable constraints or criteria for success.
Three of the major Agile approaches are Scrum, XP and DSDM:
One of the major developments in thinking in Agile has been a to re-evaluate what should be done in situations where all criteria of success cannot be achieved and trade-offs have to be made – when something’s gotta give:
Traditionally the scope or features remained fixed with time, cost and possibly quality having to flex. In Agile time, cost and quality are fixed and features are flexed. Hopefully to be included in a later iteration. The breakthrough in thinking is that in many developments, too much time is spent upfront, planning and designing based on imperfect or no information, based on what customers think they want, based on technology that is changing. The Agile approach recognizes an imperfect world and tries to adapts to it in the most pragmatic way. This will not work in all circumstances. I’m sure we have all won customer contracts that include developments that are very uncertain but “cast iron” promises have been made to customers on price, on time, on features and on quality. But as I said earlier, good tools don’t make up for bad circumstances or bad management.
This approach of developing in fixed time cost increments with usable releases at the end of each increment getting customer feedback on working software (service, product) can reduce risk, reduce cost, improve quality and be more adaptable to change. It is a seductive and compelling argument. That and the name Agile (who does not want to be agile?) has meant that Agile has become a meme that is having an increasing impact. It has become about values and behaviours, more about being agile than doing a specific Agile methodology. This is sometimes dangerous as it means that conversations can become confusing especially as media and companies will use the term agile to increase hits or attract attention. But its always the way with ideas whose time have come, that have crossed the chasm and are ripping through the rest of the market.
Scrum is the most popular approach for team management at the product delivery level. Data from Forrester’s Q3 2013 Global Agile Software Application Development Online Survey indicates that a whopping 90% of all teams practicing Agile development have adopted Scrum.
User stories in the form of “As a <type of user>, I want <some goal> so that <some reason>” are used to create individual requirements that go into a product backlog that is prioritised by value. Those that are committed to be delivered in the iteration or next development cycle called a sprint are put into the Sprint backlog. Sprints can be from 1 week to a month depending on the development environment.
Daily scrum meetings are stand-up for 15 minutes where progress is monitored, commitments made and impediments aired.
There are weekly planning and review meetings . Artifacts are light and include the product backlog (requirements), sprint backlog ( deliverables in this sprint), burndown charts (a monitor of value delivered and sprint velocity).
A comparison of Waterfall and Agile is shown below. Please note that either tool in the wrong hands can deliver poor results and in the right hands can deliver excellent results. It’s a matter of choosing the right tool for the job.
Attribute | Waterfall | Agile |
Communication Bias | Written | Face-to-Face Conversation |
Artifacts & Ceremonies | Heavier | Lighter |
Documentation | Heavier | Lighter |
Customer Relationship | Negotiation | Collaboration |
Change | Costly- Control | Less Costly-Welcomed |
Risk through project | Risky till end | Risk decreases throughout |
Management | Command&Control | Trust to Self Organize |
Prioritisation | By Plan | By Value |
Delivery | At end or large increments | In smaller increments |
Design & Planning | Mostly Upfront | Minimal Upfront&Throughout |
When Something's Gotta Give | Time&Cost | Scope or Features |
Strength | Large Scale Projects | Innovative software development |
Questions | Stifle Innovation? | Corporate Governance and Project Management? |
Team Size | All Sizes | Optimally Smaller |
Team Location | All Locations | Optimally Co-Located |
Predictability | Can be more | Can Be less |
Learn and Improve | Yes | Yes |
Titles really are a mess. What one company calls a product manager, another calls a product marketing manager. It is best to be aware of this and to focus on the activities required. Also where these people do not exist in an organisation other departments fill the void. So the activities may be performed (poorly) by technical, sales, operations or marketing communications.
Typically the title “product manager” is used to signify people who listen to the market and articulate the market problems in the form of requirements. And the title “product marketing manager” is usually assigned to those who take the resulting product to the market by defining a product marketing strategy.
In Crossing the Chasm, Geoff Moore defines (and recommends) two separate positions:
“A product manager is a member of either the marketing organization or the development organization who is responsible for ensuring that a product gets created, tested, and shipped on schedule and meets specifications. It is a highly internally focused job, bridging the marketing and development organizations, and requiring a high degree of technical competence and project management experience.”
“A product marketing manager is always a member of the marketing organization, never of the development group, and is responsible for bringing the product to the marketplace and to the distribution organization… it is a highly externally focused job.”
In reality, there is a blurring of activities and the captions used (talking and listening) are used for simplicity, clarity and guidance rather than laws. The activities performed by the roles are as follows:
In organisations where a Director, Product Strategy exists then they may take on more of the strategic and less tactical activities.
Targets are not met. Customers are not acquired. Pipelines are not healthy. Forecasts are not met.
Often the immediate reaction is to blame the sales personnel. Typical questions are: Are they working hard enough. Are they working smart enough? Do they have the right relationships. Are they looking in the wrong places. Do they understand customer problems? Do they understand the product value? Can they present the value of the product effectively?
While sales personnel can always up their game, in many cases the root problems can be elsewhere. If Product Management and Product Marketing processes been ignored, or not done correctly then the following problems may be diagnosed
A solution must then be created and delivered. Depending on the organisation this may be done by Product Management and Product Marketing.
Product management is inward focussed and product marketing is outward focussed.
Project management methodologies and tools can be used as appropriate to deliver solutions efficiently and effectively.
Leadership & Management are confused much of the time. What is the difference? The following has been extracted from an article in HBR by John Kotter. He expresses it well in my view.
It is important to stress that it is wrong to romanticize one to the detriment of the other. Both are very important. In a world of rapid change and ever more complex organisations we need both to be at the top of their game…but they are different and confusion does not help.
The mistakes people make on the issue are threefold:
Mistake #1: People use the terms “management” and “leadership” interchangeably. This shows that they don’t see the crucial difference between the two and the vital functions that each role plays.
Mistake #2: People use the term “leadership” to refer to the people at the very top of hierarchies. They then call the people in the layers below them in the organization “management.” And then all the rest are workers, specialists, and individual contributors. This is also a mistake and very misleading.
Mistake #3: People often think of “leadership” in terms of personality characteristics, usually as something they call charisma. Since few people have great charisma, this leads logically to the conclusion that few people can provide leadership, which gets us into increasing trouble.
Management is a set of well-known processes, like planning, budgeting, structuring jobs, staffing jobs, measuring performance and problem-solving, which help an organization to predictably do what it knows how to do well. Management helps you to produce products and services as you have promised, of consistent quality, on budget, day after day, week after week. In organizations of any size and complexity, this is an enormously difficult task. We constantly underestimate how complex this task really is, especially if we are not in senior management jobs. So, management is crucial — but it’s not leadership.
Leadership is entirely different. It is associated with taking an organization into the future, finding opportunities that are coming at it faster and faster and successfully exploiting those opportunities. Leadership is about vision, about people buying in, about empowerment and, most of all, about producing useful change. Leadership is not about attributes, it’s about behavior. And in an ever-faster-moving world, leadership is increasingly needed from more and more people, no matter where they are in a hierarchy. The notion that a few extraordinary people at the top can provide all the leadership needed today is ridiculous, and it’s a recipe for failure.
I recently had the pleasure of working inside John Lewis and experiencing first hand how they deliver customer service that’s admired. I enjoyed working with the company. The customers and staff (partners) are in general happy, very polite and helpful and the company has a great atmosphere which is a credit to them. This has not happened overnight. The trust that customers have in John Lewis takes a long time to build but much easier to lose. How have they created this? First are the founding principles of Customer Service in John Lewis –
“Be honest; give respect; recognise others; show enterprise; work together; achieve more.”
Then my impressions…
This is a simple idea but one few companies really put into practice. John Lewis implement it in a number of ways: