Archive for the ‘Project Management’ Category

Project: Migration to Google Apps – Google Change Management

Comments Off on Project: Migration to Google Apps – Google Change Management
September 10, 2015 · by Ray · Business Solutions, Project Management

 

going-google

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:

  • Why are we switching?
  • What happens to my old email and data?
  • How will I get up to speed?

It ensures

  • Faster adoption
  • Increased productivity
  • Greater return on investment

Get Ready, Communicate, Train

You’ll find many models for change management. Google use the simple one Get Ready, Communicate  and Train.

  • Get ready: Includes tasks to understand your organization’s culture and people, and the support they’ll need to make a successful transition to Google Apps. Typical readiness tasks include profiling your user community, sending a user readiness survey, and establishing a Google Guides program.
  • Communicate: Includes tasks to get your users excited about the switch to Google Apps. Typical communications tasks include creating a communications plan, launching an internal marketing campaign for the switch to Google Apps, and sending messages to users.
  • Train: Includes tasks to educate users about Google Apps. Typical training tasks include creating a training plan, launching a training site, and conducting courses. Historically users had never been trained on Lotus Notes and so expectation levels were low.

What changes are managed?

  • Product changes—Any new tool requires time to get users up to speed. Most users can start reading and sending messages in Gmail within minutes, but power users in your organization—executives or administrative assistants—may need more support or training.
  • Policy changes—Google Apps offers lots of new features, and your organization must decide how to use them. For example, if users can now access email on their phones, does this affect your mobile device policy?
  • Process changes—Some internal processes or procedures may change with Google Apps integrated into your environment. For example, if your organization used shared mailboxes to manage mail queues, you might update some processes to use Gmail with Google Groups.

The Google Apps Rollout Project Plan

For a Medium to Large company of 250 or more employees, a standard Google Apps transition is divided into four phases:

  • Phase 1: Core IT
  • Phase 2: Early Adopters
  • Phase 3: Global Go-LiveEach phase generally lasts about four weeks, although this varies with the size of your company and the specifics of your legacy system. The transition is usually complete within 90 days.During each of the three phases, you progressively configure more Google Apps features, migrate more data from your legacy system, and move more of your users to Google Apps. For a larger company then Phase 3 can have a number of sub phases as the employees are split into manageable sub phases. In this case phase 3 included 4 phases (Blue, Red, Yellow and Green).
  • Phase 4: Life After Go Live is about ensuring that adoption moves from Basic to Advanced as required by the user. This may involve more training and support.

Each of the phases  includes a project plan that will include Get Ready, Communicate and Train modules.

For more detail please read this document.

 

 

 

Is my Prince now a frog?

Comments Off on Is my Prince now a frog?
February 26, 2014 · by Ray · Project Management

frog-prince2v2Is 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:

  • Certain projects do not require an agile approach
  • Certain projects prefer a blended (waterfall and agile) approach. It was seen in my last post that the term Water-Scrum-Fall has been termed to indicate that the market currently seems to prefer ( or pragmatically accept) such a blended approach.

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 Structured Project Management

PRINCE2 is a formal, structured approach to project management. It recognises that there are three major levels of activities:

  • Direction (Management Sponsorhip)
  • Management (Project management)
  • Delivery (Solution development and delivery)

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:

Prince2-Process-Trans

In fact, the 2009 revision to PRINCE2 reiterated its underlying simplicity by recognising explicitly seven principles:

  • There is continued business justification for a project (or you should stop!).
  • There are defined roles & responsibilities (everyone knows what they should – and should not – be doing).
  • Manage projects by stages (bite-sized chunks are easier to track).
  • Manage by exception (don’t micromanage or meddle when things are going fine).
  • Focus on products when you plan (think things you can measure and tick off a list, not open-ended tasks).
  • Tailor the process to a project’s size, complexity etc.
  • Learn from experience! If that didn’t work last time, change it!

It doesn’t say anything about how you should build your products.The only things PRINCE2 says about making things is the following:

  • focus on products when you plan;
  • break down complicated products into smaller ones, until each unit needs around 5-10 days’ effort to build;
  • factor quality procedures into your building process;
  • have a mechanism to hand a product-to-be-built over to the technical team – a spec of some kind (PRINCE2 calls this a “workpackage”) – and a way to sign off built products that come back.

PRINCE2 and Agile as a Blended Approach

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!

Project-Mgt-Frameworks3

 

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.

What about “Just Agile please”?

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.

DSDM-Artefacts

 

Journey-so-far,-1-project-f

 

disciplined-agile-delivery

Can an elephant be agile?

Comments Off on Can an elephant be agile?
February 26, 2014 · by Ray · Business Solutions, Project Management

Who says you can’t be big and agile?

agile elephantLou 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.

Different customers  require different approaches

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.

  • Management need a business case. A new product development  requires investment and a return on that investment within a specific time. Management require a business case and a plan and a commitment to deliver. Sufficient planning and detail is required on what will be delivered and when.
  • Operations require predictability. They require new features at a specific time in a way that can be launched without causing outages, or downtime on critical services.
  • Complex projects need co-ordination and formal communication. In complex projects with multiple teams they will be dependent on each other to deliver specif items with specific features at a specific time.
  • Customers have their own preferences. They may or may have the time to be giving constant feedback
  • Are the requirements stable and known, or unstable and unknown?
  • Do critical and expensive resources require to be scheduled?
  • Development teams can only predict so much. The only risk free prediction is when it is delivered. Documenting the future may kill the future.

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.

But approach is only a part of a successful solution

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)

I’m definitely agile

Comments Off on I’m definitely agile
February 26, 2014 · by Ray · Business Solutions, Project Management

Agile & Waterfall

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”.

agile&waterfallA 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 plan

That is, while there is value in the items on the right, we value the items on the left more”.

Agile: From Software Development to Business Change Projects

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 :

  • In an iterative and incremental way. In each short phase a delivery team will build part of the system and test it and customers will have some working functionality.  Priority is given to development of most value to the customer. User feedback is used to improve functionality in next iterations. Risk is reduced throughout the project as deliveries are made.
  • By responding to change. A delivery team can respond to valid changes to requirements, changes in technology or customer change.

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.

Agile: Three Major Approaches

Three of the major Agile approaches are Scrum, XP and DSDM:

  • Scrum – Team Focussed, Light, Empirical Agile
  • eXtreme Programming (XP) – Engineering focussed, Technical, disciplined Agile
  • DSDM – Project focussed, scalable, governable Agile

Agile: A New Paradigm for When Something’s Gotta Give

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:

Triangles-diagramMod

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.

Agile: A New Risk Profile

agile-value-deliveryV1This 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.

More on Scrum

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.

Scrum-ProcessV2

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.

10-scrum-rules

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).

Agile & Waterfall Comparison

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