10 Tips to Successfully Manage Outsource Projects


Companies can consider to outsource projects because of different reasons:

  • To reduce cost
  • To reduce time to market
  • To work on non-core or high value projects
  • To work on operational / repetitive projects
  • To work on non-volatile projects
People doing a puzzle
Tips on how to outsource projects

I have managed outsourced projects where we met the deadline but did not save the money we were supposed to save and also I have managed outsourced projects where we saved the money but did not deliver what the users required.

If you need to outsource a project team review the following 10 tips to successfully manage outsource projects:

  1. Qualify the vendor, does the vendor have domain knowledge (technical, design, user experience, data, etc)?, is it financially viable?, for how long has been in business?, can you speak with some of their past or current clients?, are there contractual agreements in place to keep control over the intellectual property you give it?.
  2. Train the outsourcing team, they need to know how the product works, from both internal and customers, they need to know what problems the customers want to solve and how the product solve these.
  3. Assign one of your best project manager as your internal project manager. This person will coordinate deliverables and handoff around the organisation.
  4. Plan for each project to take longer and cost more, especially at the beginning of an outsourcing relationship. Consider to increase time by 25% for the first project, you can always review forecast vs. actual and reconcile.
  5. Develop a trusting relationship with the project manager at the outsource company to help you understand the reality of what is happening in the project.
  6. Try to accommodate your team shifts to the outsourcer working hours, if due to timezone difference this is impossible, try to make out the most available hours for both teams, so that people can make time to talk to each other.
  7. Select outsource projects with non volatile requirements. If your requirements change frequently and you need to check and iterate the evolving product with the end-user, development across the world makes that much harder (not impossible, just harder).
  8. Document the requirements / product backlog (using a wiki as best option) and have this always accessible and visible for the team. If your native technical staff can’t “sometimes” read your mind about what you require, how can geographically distant and non native English speakers understand your requirements?
  9. Insist that the outsourcing company keep the same team for your project’s duration.
  10. Make sure you have ALL the tools, information systems and processes in place to support the outsourced teams. To start they will need access to the source code, database, platform applications, builds, assets etc.

These 10 tips will help you to successfully manage outsource projects and to deliver more value to your users and company.

5 Levels of Agile Planning


Within Agile, planning is done continuously. Planning is about working out what to do, and that must come before working out how long it will take.

In this post I would like to present a process that will allow team members to understand the whole sequence of planning from vision to user story.

5 Levels of Agile Planning

Level 1, Vision:

Every product needs a vision, a destination postcard that will guide the team towards the goal. The vision also helps to have a keen eye for opportunities, to focus on value (to the user and business) and return on investment (ROI). Every decision is taken with the product vision in mind. This ensures clarity for the development team and increases the chances of success.

Level 2, Roadmap:

This is a long-term product strategic roadmap (from 3 to 6 months max), this can also be explained by de-composing the vision into phases in a logical order. The roadmap will help to see how the product would evolve.

Note that it does not usually make sense to make a plan based on user stories that go further out than three months. Beyond this point, use a road map based on story themes.

Level 3, Plan Releases:

If the roadmap gives the phases, the release plan de-composes each phase into sprints. These sprints are conditioned by the roadmap; market conditions the status of the product. The product backlog consists on more than only features, for example: technical requirements, bugs, defects, spikes, non-functional requirements that should be taken into account.

Backlog refinement is very important, this must be granular and well understood by the whole team.

Level 4, Sprint Planning:

During the sprint planning the team plan and agrees the prioritised product backlog stories they are confident they can complete during the sprint and help them to achieve the sprint goal.

Here are 3 basic steps to create a plan:

  1. Understand priorities: Start with the team a conversation about the user stories the product owner would like to get in the next iteration to release.
  2. Size the work: 
When the stories are understood, help the team work out what needs to be done to deliver the stories.
  3. Agree on the plan: 
Wrap the meeting up by getting agreement on what can realistically be delivered.

Level 5, User Story:

If the team members want to deliver valuable software, they need to go the extra mile to understand both user and business benefits, and user stories help them do that. User stories underpin all the work an Agile team does, they are the basis of plans, development and testing.

The whole point of user stories is to ask questions to better understand what users need and to find ways of breaking requirements down. Break the tasks into smaller pieces so that everyone has a deliverable every day.

User stories are a simple technique that a team can use for understanding their customer through talking about what users need.

The main point is that Vision must drive decisions and User Stories are the means to achieve that vision.

Scaling Up and Rolling Out Change


Kaiser Permanent (KP) is the largest integrated healthcare system in United States, the facts as of 2014 are over 10 million members, 177,000 employees and with annual reporting revenue of $56.4 billion.

doctors

KP undertook few years ago a scaling journey to develop and implement electronic health record systems with the goal to make life better for patients and employees.

KP suffered a string of failed attempts to develop. The turning point came when its leaders realised that to scale up the record systems to all KP hospitals  needed to do things very differently.

Before the scaling effort, KP had endured a decade of failed efforts to implement electronic health records.

Between 2004 and 2010, KP scaled up KP HeatlhConnect. The scale up journey started by first being implemented in one of the smallest regions, Hawaii between 2004 and 2006, then rolled out the largest region, Southern California in 2008 and it deployed to LIVE in every region by 2010.

The leader of this initiative was Dr. Louise Liang and their team took a different approach to make this a success. They understood that the biggest obstacles to spreading the mindset across KP and rolling out the system was that hospitals operated under a paradigm of siloed regions with a weak relationship to shred functions. To succeed, KP required a lot more collaboration among regions.

However, understanding the history and culture of the local autonomy, the delivery team couldn’t insist that the exact same system be implemented in the exact way in each region, the team had to balance 3 constraints: commitment, creativity and customisation.

KP HealthConnect required local leaders to learn from and imitate other regions; Hawaii’s early success created challenges because, in the past, large regions like Southern California dictate and set the tone for changes across the entire organisation.

Starting in Hawaii was a great option, they were hungry for change, serve a smaller patience and medical audience and took less time; when the rollout was complete, initial fears and resistance vanished, and local doctors, nurses and patients reported that the system was making their lives easier.

Another reason why Hawaii succeeded was that in contrast to many other KP failures in the past, they didn’t implemented alone. The delivery team along with leaders from all other regions travelled to Hawaii to observe and help out, providing lessons and hands-on experience that guided and accelerated the roll out process.

The delivery team master a balance between standardisation and customisation, by specifying few critical constrains “non negotiables” for each region, this helped to ensure that each roll out was efficient, regions could learn from each other experience and users could learn faster to use a common system.

The non-negotaibles:

  1. the name: KP HealthConnect this reinforced the “one” solution mantra across all regions
  2. interoperability: no modifications could be made to the system that reduced the KP’s ability to maintain a single and integrated system, any software developed as a result of a customisation by a region, hospital or function had to work well with the rest of the system
  3. common data mode:  every local system had to use uniform data and definitions. This enable each region to generate consistent and comparable data so performance differences could be identified, problems spotted, improvements made and comprehensible reports generated.
  4. configuration no customisation: when Dr. Liang took charge, more than 300 contractor were working on customisations, this increased risk and maintenance costs. The delivery team understanding the need to provide fit to purpose solutions, allowed regions to select their own configuration, but they say no to programs that were built or designed differently from the system.

The operational model was also different, for instance when a new region went LIVE, teams from other regions that had already completed the implementation and deployment were “on loan” ready to support, guide and learn.

The learning in this case is:

Risk goes down and efficiency goes up when leaders and team complete a template that they can see and touch. It’s easier, faster and cheaper to imitate solutions that work elsewhere rather than to invent something from scratch every time.

Read more: Hayagreeva Rao and Robert I. Sutton. “Scaling up Excellence“. Random House Business.

What is Business Portfolio Management?


Portfolio refers to the total set of programs, stand-alone projects and other change initiatives undertaken by an organisation.

Portfolio Management

The reason for creating a portfolio is to provide an overall business view and control over all these programs and projects at a high level in the organisation.

Portfolio management is aligned to the organisation’s budgetary and decision-making processes and is the link between the corporate and business strategy and the programs and projects that will deliver it. Portfolios have strategic corporate deliverables and are ongoing.

  • The overall corporate strategy is implemented through the business strategy, the portfolio is aligned with the business strategy.
  • The business strategy is then implemented through the programs and projects that make up the portfolio.

Portfolio management ensures that all projects and programs stay aligned with the business strategy and deliver business benefits.

By treating the totality of the organisation’s programs and projects as a single portfolio, they can be ranked on their alignment with corporate strategy and their potential business benefits.

The goal is to ensure that the portfolio delivers in line with the business strategy of the enterprise.

Portfolio Management key objectives:

  1. To maximise the value of the portfolio by achieving the best possible return on investment
  1. To align the portfolio with the organisational strategy
  1. To balance the portfolio by making the best possible use of the organization’s human and financial resources

Program Management Governance in Few Words


The first thing the program must do is establish program governance by planning how it will monitor and control the constituent projects.

Program Governance

Effective governance ensures strategic alignment, the realisation of promised service and benefits, stakeholders are communicated with and kept aware of progress and issues; appropriate tools and processes are used in the program; decisions are made rationally and with justification; and the responsibilities and accountabilities are clearly defined and applied. All of this is done within the policies and standards of the partner organisations and is measured to ensure compliance. Program Governance is intended to provide:

  1. A framework for efficient and effective decision-making
  2. Consistent delivery management with a focus on achieving program goals
  3. An appropriate mechanism to address risks and stakeholder requirements

Governance is about structured decision-making on investments in projects as has been summarised as the four areas:

  1. Are we doing the right projects?
  2. Are we doing them the right way?
  3. Are we getting them done well?
  4. Are we getting the benefits?

What criteria to use to select the right programs?

There are 5 selection criteria for organisations to evaluate what programs to start, being the strategic fit and benefits analysis the most important ones.

  1. Strategic fit: how well the program fits with the business strategy of the organisation
  2. Benefits analysis: what the benefits to the business are and how they will be achieved
  3. Budget: the preliminary budget estimate for the program
  4. Resources: the human and other resources required for the program and their availability
  5. Risks: analysis of the potential risks to the program

What are the Responsibilities of a Program Manager?


We know that programs are longer-term collections of related projects and other activities that will be managed in a coordinated way.

Program manegement

A Program manager goal is not about managing the details of each individual project, but rather about managing the big picture, in order to achieve the strategic objectives and realise the benefits for which the program is designed.

What are the Program Manager tasks:

Program Manager is responsible for leading and managing the program from its initial set up, through the delivery of new capabilities and realisation of benefits to program closure. The program manager has primary responsibility for successful delivery of the new capabilities and establishing program governance.

  1. Managing the inter-dependencies between the individual projects in the program
  2. Prioritising issues that arise from different projects
  3. Making sure the strategic goals and objectives of the organisation for which the projects are being executed
  4. Realisation of benefits from the program
  5. Management of stakeholders
  6. Management of program risks
  7. Oversee the projects in the program and provide high level guidance to the project managers

Management Skills of a Program Manager:

  1. Change: not only expect change but actively encourage it in order to maximise the strategic benefits of the program
  2. Leadership Style: focus on managing relationships, conflict resolution and the political aspects of stakeholder management
  3. Management skills: need to provide overall vision and leadership
  4. People Management: manage the project managers
  5. Planning: responsible for performing high level planning and providing guidance to project managers for their detailed project planning
  6. Success: measured in terms of return on investment (ROI), benefit realisation and new operational capabilities delivered by the program

What is a Program?


A program consists of a group of related projects and activities, managed in a coordinated way, in order to deliver outcomes and benefits related to the organisation’s strategic objectives that would not be available by managing each project individually.

Programs are the link between the business strategy and the individual projects that will implement the solutions required to deliver it.

Program Management

Programs usually span several years and therefore the scope, time and cost are likely to change during the life of a program.

Program management is not about managing the details of each individual project, but rather about managing the big picture, in order to achieve the strategic objectives and realise the benefits for which the program is designed.

Benefits of Program Management:

  1. Optimisation of human and other resources over multiple projects in the overall program
  2. Coordinated management and reduction of risks
  3. Consolidation and management of the benefits

Why a to create a Program?

  1. The program is too large to be treated as a project and the component projects are too interdependent to be treated as separate unrelated projects.
  1. To optimise the use of scarce resources by sharing them across several related projects in the program.
  1. To keep the projects aligned with strategic goals and benefits.

Phases of a Program

Program Definition: involves understanding the strategic value of the program, defining the program objectives, identifying the key stakeholders and decision makers, developing a high level business case for the program, obtaining approval for the program and appointing the program manager.

Benefits Delivery: represents the main ongoing program management activity and for each of the constituent projects this will entail planning, execution and benefits realisation. For the program as a whole it also involves managing the inter-project dependencies, risks and issues.

Program Closure: performs a controlled close down of the program, together with the shutdown of the program infrastructure and transition of benefits monitoring to an operational group.