I have recently moved from a loosely controlled food regimen to a fairly establish set of rules about what I should eat and what I should not. I have been contemplating writing this post for a while, just for fun, and use dieting as a way to introduce the difference between a project and a business as usual endeavour.

What are we trying to do here?
As usual this question is a great helper. What’s your goal in dieting? Is it to lose a specified number of kilos before next beach holiday? Is it to be healthier and in that case what is a measure of health?

If your goal is to reach a specific weight for your next beach holidays then that’s a pretty clear deliverable with a timed based objective. It’s a project.

You’ll design an approach to get to that objective – i.e. chose your dieting method – stick to this approach and control progress (weight scale every so often). If progress are not inline with the expectations then you’ll make changes to your diet. Eat less of this, exercise more. That’d be change and quality management.

The project completes when the holiday comes. No slippage allowed here. No tolerance on timing. In a way you’ll have to accept the deliverables as they are (you!) and be happy with it or not. Weight loss might be the key measure of success.

If your objective is to achieve long term health and weight control as part of it then you are not only embarking in delivering specific results for a specific date. You are also going to put in place a new system to be used on an ongoing, business as usual, basis to build and maintain a ‘health’ level. This not really a project anymore as there is no ‘end’ date to it. This is a process management activity whereby you’ll monitor specific KPIs (weight, blood tests results, blood pressure, body fat % and so on). This is not a project as there are no time based deliverables. However you’ll still need to monitor the diet outcome and make adjustment to perfect the results. It’s more a process improvement exercise.

This said we can nuance this a little. As you start your diet with the aim to reach a long term goal of weight control and health, most diet usually includes an intervention stage to start with. This stage could be seen as a project: it’s time based and very controlled. Once this stage has completed you’ll switch to a maintenance mode – which is really the business as usual process.

Does this comparison makes sense to you?

…is “Agreed all customer facing textual and visual elements of our product”.

Even worse: estimating is hard but sticking to an agreed timeline is even harder. Obviously the more the people having a say the bigger the nightmare.

So the technique might well be:

1. You guys think about those elements, maybe brainstorm a bit or a lot, do this regularly.

2. Here is the deadline.

3. x days before the deadline: start a sprint to get everything agreed. War room it. (x depends on the project).

4. Deadline is reached. End of story.

What do you think?

Gantt Charts are an essential tools and outputs in project management. If you are in the profession you’ll know that when management asks for a plan they expect to see a Gantt Chart with an end date [that matches what they want]. So project managers do feel the pressure to get one done and agreed. It’s a tyranny.

Gantt charting tools are widespread (and sometimes free) – so it’s very easy to get started and build one for your project so you can quickly build dependencies between tasks, calculate critical path, assign resources to tasks and so on. You’ll use the Gantt chart as a communication tool first then as a monitoring and control tool. It’s great.

Project managers should however not jump straight into producing a Gantt Chart but first concentrate on agreeing a scope of work with a set of deliverables and decide on an approach to producing those deliverables. Only when this is clear [clarity would generally comes with an iteration of the planning activities] you can start building a Gantt Chart that will detail the tasks to be done in order to build those agreed deliverables.

Gantt Chart being a task driven tool it is easy to get carried away and forget the deliverables to build and the driving approach to deliver them. The risk is to end up with a plan that will forget some deliverables or use the wrong approach for this particular project.

I recommend to spend time with your team and stakeholders to clarify the deliverables, decide on the best approach for the project (including iterative approach for all or some of the deliverables) and then get going with Gantt Charting…if needed.

On the PMI Blog, a short article on the role of Executives in Lessons Learned and how to engage them.

You, the project manager, must engage upper management in the discussion. Review the timeline and other milestones that took place on the project. Upper management could talk about how the goals of the project and the team’s successes intertwined with the strategic goals of the company.  The team would appreciate this perspective on the significance of their activities.

It goes beyond talk, share and listen. With regards to Executives lessons learned can be split in two:

• Learnings that can be applied without the support of Executives: incremental improvements to processes, recommendations, tools we are using, way we deal with requirements, information, reporting…
• Learnings that need Executive support – learnings that suggest radical changes to the way and why we do projects: your lessons learned session would identify those learnings and develop possible actions. You’ll have to sum them up in a concise  summary and go and engage the Exec with it.

Definition: the quality control technique consisting in testing the product or
service being created as the final customer would use it. Testing is usually performed by the whole organisation. Usually applies to start-up as the level of care in what is being produced is usually higher than in established organisations, making the execution of the tests more trustworthy.

(Editor’s note: This is a Guest Post by Jason Westland from MPMM.com)

Being assigned to manage a project can be tough and often times daunting. There are the possibilities that no matter how well laid out your plan is and even with an extraordinary and talented team, there will be risks and challenges along the road that can be the cause of the project’s downfall.

Given that challenges are a fact, the question really is, how will you manage when such a time arises? What project management steps that you as the project manager need to follow? This article will answer your questions and will help in breaking down the process on how to use project management steps.

There are 8 vital Project Management Steps that are essential for a project manager to know and as much as possible abide by. The first and foremost step is to create an outline of the project scope. The project manager must be able to identify what the goals and objectives are of the client so that when the project planning begins, the project manager is able to convey what the client’s vision is. The project manager should also be familiar with the project management phases and use that as a manual in accomplishing the project.

The second step is to establish what resources are considered necessary for the project. A thorough research should be made to calculate how much a project will cost, how many people, equipment and material is needed. The project manager may also use any available project management software that is out in the market to assist him or her. This is especially recommended if the project will be large and complex.

The third step is to create a timeline for the project. How long will this project take and given the resources available, when will you be able to complete and deliver the project to the client? The reason for this is simple, once the objectives are set into motion after the project planning stage, costs have begun to accumulate. As a project manager, you will need to be able to budget the project’s funds, the   number of hours the people in your team will work, and the resources available to you so that you will not run out of it even when a risks or mistakes are made. This will allow you to adjust accordingly to needs of the project without exposing it to too much danger. Again, using a project software, especially one that has project tracking applications is recommended as this would help in tracking schedules, events, timelines, calculating critical path, etc., depending upon your set requirements.

The fourth step is to gather your team and then list down the processes that you as a group will follow.  As a project manager, when assembling your team, you must be able to choose a member not only for their technical expertise on the project but also their ability to relate and interact with each other. Once all the experts needed for the project is complete, a project manager must be able to effectively pass on the vision and the needs of the client is so that they may provide the steps necessary to attain the objectives.

The fifth step is to develop a plan using the steps determined by you and your team. The project manager will need to learn to adjust and prioritize what step should be accomplished first, what is important and what can be set aside or what should be removed entirely. Always communicate with your team and ask what their opinions are especially when there is a need to make adjustments. To make this a lot easier, detailed and documented, the use of project software applications would be of a tremendous help.

Monitoring and Controlling would be the next essential step as this would aid you in minimizing and controlling any risks. Whether it is the lack of materials, budget constraints or people issues, a project manager should be always up to par with the progress of the project.

The project manager should also record the processes, changes and the other pertinent facts about the project so that when the project closes, you will have a detailed report of the project that you may use in any future analysis of the project or if a new project that is similar to the current will come up. Lastly, a project manager should always follow the open communication step. This means that you keep everyone informed about the progress, the problems encountered, the changes or adjustments made to both the client and the team. This would build trust among the team and the client and always be willing to listen to their suggestions. Always consult before any major decisions are made.

The project management phases basically encompass all these steps, and a project manger should always use these steps and phases in order o succeed in any endeavor.

To find out more about Jason Westland, the author of this article, you can visit MPMM.com and learn about Jason’s Project management methodologies.

(Editor’s note: This guest post is provided by Jovaco Solutions)

Project management is no easy task, and can often be a thankless one as well. With projects that include over-demanding clients, creeping requirements, and uncompromising bosses, it is no wonder project management can be a stressful endeavor. Here are seven habits project managers should adopt to avoid falling prey to blown budgets and failed deadlines:

1. Be proactive.

Keeping one step ahead of project issues will make you better prepared to tackle project difficulties as they come. One example is to know what your past project variances are. Employ your project accounting software to track your previous project estimates for things like time and cost versus what they actually ended up to be, you can better plan in the future based on the accuracy of these past values. Another example of being proactive is to try reducing costs during design, developing better requirements, detailed designs, and prototypes early on in the project life-cycle. Putting your best foot forward is always a good idea. Effective communication is always a great way to be proactive, communicating effectively on a daily basis to keep everyone up to date on each other’s status. This can be done in person, via e-mail, or through discussion forums. Daily meetings can provide full transparency, as there are no surprises if everything is regularly reviewed. Daily meetings keep status reports fresh, allowing for proactive resolutions if the project begins to slip.

2. Think about the end in the beginning.

Make a list of success criteria that you judge the project on. Doing this up front allows the project to be evaluated for meeting this criteria or not. Projects are measurable this way and offer better team buy-in. A novel approach to this is to develop the user manual for one’s product or service before actually beginning development. After all, it is the user manual which describes how the product or service should operate in the first place, right?

3. Put First Things First.

Prioritize and apply effort to the most important things first. Prevent feature changes and enhancements disguised as defects from adversely affecting your priorities.

4. Think Win/Win.

Foster a win/win relationship between your team and clients. Allow for the “Features-Time-cost” project management pyramid to have flexible variables, as failing to do so risks team burnout or loss of future business with the client.

5. Seek to understand, then to be understood.

When beginning any project management task, it is absolutely vital that you listen to others first in order to fully understand the problem. Most people want to be heard rather than hear. Hearing others first allows for multiple solutions to be entertained, provides better discussions in the future, and facilitates the ability to solve a problem in a more direct way.

6. Synergize.

Team collaboration is an absolute must to a project’s success. Teams with various skills, strengths, and backgrounds can positively contribute to a project’s development, especially when they work together as one cohesive unit. Offer tools that maximize a team’s effectiveness, keep track of their tasks and share their statuses with other teammates.

7. Hone your skills.

Things change these days faster than ever. Learn new techniques and keep your skills up to date. Invest in learning project management skills like PMI, ITL, CMMI. Not only will they keep you on top of your project management game, but constant lifelong learning keeps the mind active and receptive to new ideas and critical thinking.

The telecommunications world is a successful example of technology standardisation. In the mobile industry GSM gave the ecosystem (operators and suppliers) a set of standards that removed a lot of technology risks, enabled the birth of a large set of suppliers and product offering and gave customers roaming benefits and interoperability.

In the area of project management itself a significant amount of work is being done to develop standards: PMBOK and Prince2 are the leading example.

Those standards are important but not enough as their practical side is not developed at all (at least for PMBOK), they are standards and not methodology. Standardisation has however not fully reached the area of project management when it comes to systems integration within a telecommunication operator environment. Why? A lot of local, cultural practices hinder the application of common approaches, but also and most importantly the variety of project sizes. Another reason is that there is no standardisation body so standards or guidelines have been defined by companies themselves often to industrialise their own processes.

So as a supplier is entering into a working relationship with an operator, it usually has to match its own process with that of the operator. In a way process integration has to happen before the integration of the product or service itself.

This article instantiate this issue and highlights some essential information about french telecommunications operators typical systems integration processes, it is mainly aimed at giving solutions vendors an understanding of the systems integration requirements that will likely to be part of their contractual obligations. This paper was written based on practical knowledge of working with three mobile operators in France. At the time of writing there are only three mobile operators in France (Orange, SFR, Bouygues Telecom) and a 4th operator (Free) has been awarded a 3g licence in late 2009.

1. Documentation

In general the documentation requirements are fairly demanding. Suppliers are likely to be asked to document:

• the logical and physical aspect of the solution,
• the detailed IP flows,
• the configuration of all elements of the system,
• the hardware set-up,
• the racking set-up and the cabling,
• the software releases notes.

Usually English is accepted – however sometimes requirements are documented in French, particularly for “standard” requirements that are imposed on all suppliers. This covers aspects such as Monitoring, Backup and Restore, Security, Remote connection, Database design, …Up to the supplier to get them translated.

Suppliers often are not used to produce all required documentation, leading to extra documentation effort and the need of specific skills for those documentation.

Tips for suppliers: Ensure documentation requirements are understood and that appropriate resources are lined-up to address them.

2. Acceptance phases

The overall acceptance life cycle should not be of any surprise to anyone in the industry. The advise here is to look into the details right at contract stage in order to make sure the work to be produced is understood. Before any attempt to deliver anything to the operator premises the supplier may be asked (not all operator request this) to perform some tests at the supplier premises, on an environment similar to that of the operator.

It’s called “Preliminary acceptance test” and should be considered as a FAT (Factory Acceptance test). This is to ensure that what will be shipped to the customer premises will actually be worth testing. Clearly one of the challenge here is for suppliers with highly industrialised processes where usually no FAT is performed.

The acceptance workflow, starts with the Technical verification (“Verification technique”) which is about the verification that the hardware, software versions and configurations are delivered as per specifications. The goal is to catch and fix any issues that would otherwise jeopardise the validity of the next – longer -acceptance phases. Practically speaking this Technical Verification step will involve: checking that the hardware matches the bill of material (servers, processor speeds, memory, hard drive space, power supplies, …), check OS and other third party software licences, checking that the configuration of the system is documented (and check that the documentation is accurate), checking that cables are labelled and the labelling documented, checking power redundancy.

Next step is Interconnection testing (“Tests d’interconnection”) which is about verifying that the supplier’s system can actually connect to the operator environment. This often means testing every single IP flow that the solution needs, even for IP flows within the supplier’s own system and testing basic use cases of the solution to give confidence that the solution is fit to enter the next step, Conditional Acceptance.

Conditional Acceptance (“Acceptance conditionnelle”, or “VABF (Validation Au Bon Fonctionnement)” which means “Functional acceptance”) is usually called “Customer acceptance tests” (CAT) outside of France. This is the lenghtiest of all phases. It is about testing that the solution delivers the product requirements. There is a high probability that the supplier is going to be asked to perform Backup and Recovery testing, Performance testing and Failover testing. Those more “operations” tests are sometimes called “VABE (Validation a la bonne exploitation)”.

Once Conditional Acceptance is granted the systems is usually ready to go live. But that’s not the end of the acceptance process. A last step, VSR (“Validation en Service Regulier” which means “Normal operation acceptance”) is required. VSR is lengthy (we are talking one to two months) but does not eat up a lot of resources. It consists in monitoring the system for a period of time and ensure that agreed KPIs are met over that period. If the KPIs are met then Final Acceptance is granted. Note that VSR only applies to the production environment.

Who does what?

This really depends on the operator and their staffing level (quality and quantity), but in most case the supplier usually drives the acceptance phases, providing test documentation, executing tests and documenting test results. French operators are usually more demanding in documentation and formalism than others. Roles and responsibilities need to be clearly understood.

Workflow: Test and Live system

As a general rule: activities on the production environment cannot start unless Conditional Acceptance is reached on the Test environment. This is a general rule however in practice Technical verification and Interconnection testing on production could be run in parallel to the Test environment Conditional Acceptance.

Tips for suppliers:

1. Ensure that the payment milestone at Final Acceptance is small and that most payment is done at Conditional Acceptance.
2. French are heavily “contract” driven so: spend time understanding your contract commitments (review those Annexes with “standard” requirements that contains things that you don’t do as “standard”).
3. Be upfront on the workload that operators are requesting from you with there documentation and testing requirements – are they ready to pay for all this?
4. Do involve a project manager during the pre-sale activity.
5. Negociate what happens to the VSR if Conditional Acceptance does not lead to an immediate go-live for reason outside of your control. This could indeed delay the Final Acceptance payment milestone.
6. If your integration staff is based abroad and travel to Paris to perform the Acceptance tests then you will be better off (and they will be happier) if you rent a flat for a short term.

3. Management: decision making, project management

As with many big organisations decision making will appear opaque, fuzzy, complex and more annoyingly: slow. This is more of a characteristic with large organisations than with French organisations, however because French corporations are usually more hierarchical than Anglo-Saxon’s the problem is more evident. The main day to day problem a supplier’s team will encounter is the lack of end-to-end ownership by the operator’s project manager.

As part of the integration requirements suppliers could find some ‘management’ related requirements. They should not overlook them:

• Quality management systems
  Operator will have an interest in the supplier’s quality management system. When no certification is available operators are keen to understand the steps taken to get to some level of certification in the future. Suppliers will have to figure out how strongly the operator feels about those requirements and this depends on the criticality of the system delivered.
• Specific reporting
  Supplier may be asked to report on project progresses with specifics metrics and KPIs. This should not be a problem or cause significant efforts.
• Audits
  Audits are always mention in a standard contract and could happen so suppliers should ensure they understand the requirements and get ready to open their HQ doors to auditors. The scope of the audits is usually the Quality management system.

Tips for suppliers:

1. Do not overlook “standard non-technical requirements” – failing to meet them could expose you to not meeting “Acceptance” and potentially could lead to penalties.

4. A few cultural tips

A few tips about french work culture and practices – take it with a pinch of salt though.

1. Meetings and conference calls. Expect people to be late for meetings and conference call. This is annoying for most but french usually find it normal to be late by 5-15 minutes. In meetings you will sometimes witness an separate discussion starting in french, in parallel to the main one.
2. Technical background. As a rule of the thumb expect attention to details specially when dealing with technical topics. The french education systems favors scientific studies over business studies and you will probably feel it when dealing with french companies. It comes to a point where the purpose of the project, the business purpose, seems to be less important than the technical aspect of the project.
3. Start late-finish late-lunch. Empiracal evidence shows that management usually tend to start their day late and finish late in the evening. So the english “9 to 5″ is more likely to be “9.30 to 7 with a 1 hour lunch break”
4. Outsourced workforce. Current employment legislation in France makes it hard for companies to decrease their workforce at will, so to limit the number of permanent employee they are using IT services companies, “Body shops”, to provide temporary workforce. The operators’ technical team usually has a good share of those temporary staff. They usually are quiet integrated. Note: the freelance market is nearly non existant in France.

5. Final words

Managing systems integration projects with French operators is usually challenging but it does not has to be this way. As with all contracts suppliers have to understand what they are signing for, getting to that understanding is where the difficulty is.

Suppliers should take particular care at pre-sales stage to understand in details what is asked from them.

During project execution suppliers should make sure that communication management is particularly taken care of to remove misunderstanding and constantly seek validation of what is being communicated, this is an extra effort required because of the generally average english speaking skills in France.

This paper suggests a standard set of phases that are involved in the provision of outsourced IT solutions and this from the Selling organisation’s perspective. Those phases are presented in relation to each other and form a Phase Review Discipline (PRD).

The phases identified belongs to 3 distinct groups, Win Business, Delivery and Support and we will discuss all three groups here but in particular the Delivery group.

This paper aims at: – stressing the strong relation between sales processes and project delivery processes, and what it means for the supplier’s organisation. – suggest a standard approach for the entire lifecycle, from sales to support, and how it benefits the organisation, – suggest what role a PMO may have in an organisation adopting such a PRD approach.

Note that we deliberately excluded product development from our analysis which does not mean there are no relationship with the phases introduced here.

PRD phases and phases groups

A “phase review discipline” or PRD splits a set of activities aimed towards the same goal into time based phases (so sequential) with each phase corresponding to a number of deliverables and milestones.
In project management a PRD aims at defining a standard approach across projects in order to enhance re-usability, enhance control over projects, standardise deliverables, facilitate communication and provide a sound base for process improvement.

Each phase is therefore associated to: – a standard set of deliverables (technical or management deliverables) – a milestone – the activities aimed at producing the deliverables

The groups
We are covering here the activities starting from the presence of a sale opportunity, through project delivery, and ending with the end of the support activities following the termination of support obligations. The three groups are Win Business, Delivery and Support. Those groups are dictated by common departmental organisation, with a clear distinction between sales and delivery teams, and delivery teams and support teams (though in case of large programs, delivery and support teams can sometimes be nearly merged).

Groups description
This section describes phases for each of the groups, the description is not extremely detailed as it should be but provides a good overview of what each of the phases is about.

Group: WIN BUSINESS

We will simplify the win business phases group to two phases: Analyse and Bid. Note that we are here reducing sales to activities dealing with a addressing a specific opportunity, we are not adressing other type of sales activities should they be internal or external.

The first phase (W1-Analyse) is generally triggered by a request for information that would give the elements to our company to understand in sufficient details what is the opportinity about, this first phase is concluded by a decision to bid or not to bid for this opportunity.

The second phase (W2-Bid) leads from the decision to bid to – hopefully – winning the business. The main outputs are the contractual, technical (requirements, high level design) and project (project plan) documentation.

W1-Analyse
Qualify the opportunity and decide if we should bid or not for this work. Is our product a match for the customer’s needs? Is the customer “strategic”? Is the opportunity in line with the business objectives for the company? Are other initiatives with higher priority ongoing?

If the decision to bid for the work is made then the scope of work for the next phase needs to be produced, essentially: what effort is needed and what skills we need to mobilise to support the bid work.

inputs: – customer’ RFI, RFP or other materials – product documentation – sales objectives

deliverables: – analysis supporting the decision – scope of work for the coming phase, including what resources are needed to undertake the S2 phase

milestones: – decision to bid or not

W2-Bid / Requirements
This is the core of the Win Business phase group, it defines the scope by matching the capabilities of the company’s products or services to the requirement, If the requirements are not defined or not clear then effort should be spent to do so. It defines the project plan: deliverables, schedule, communications plan, risk plan, resources plan. This is where the planning effort is essential.
The design of the solution is a product of this process, it needs to be done in sufficient details to allow the planning of the project and the validation of the technical feasibility of the project.
This is probably the most important phase of the project – even if it has not started yet as the contract is not awarded, any changes to the scope of the project after this phase is very likely to have impact on the contract itself. Key resources to support this process: pre-sales consultants, project manager and solution architect, also inputs from product managers are often required. In important to realise that this Win Business phase is heavilty supported by resources more commonly assigned to the project delivery.

inputs: – customer materials (RFI, RFP), W1 outputs

deliverables: – agreed requirements – solution design, scope of work, scope description – contract – project plan (with at least the first part of the project planned in details)

milestones: – contract award decision

Group: DELIVERY

It follows the Win Business phases group and so kicks off once the contract is awarded. The project plan should already be produced and validated – though maybe not in too much details – this phase is really about delivering the work and updating the plan as we go along.
The processes in this phases group are organised like a traditional waterfall model lifecycle, however it does not have to be this way OR it can be adapted as see fit.
This process group would belong to the Operations side of the business rather than the Sales side, this is important as this would require significant collaboration and communication to ensure smooth transition from one to the other, task often overlooked.

Phases are: – D1-Design – D2-Build – D3-Verify – D4-Validate – D5-Launch

D1-Design
First, there is no Requirements phase here as one would expect. The work to establish the requirements is part of the Win Business phase group instead, in the Bid phase.
Even the design for the solution is itself largely known as it is required to support detailed pricing for the contract.
This phase concentrates in clarifying the elements of the solution design that need to be worked on further, also it finalises the detailed requirements (should it be necessary)
But the key delivery of this phase is the detailed design.
Those technical deliverables are now in the hands of the project team that is build up at the beginning of this phase, prior to that the team involved is the sales team with technical leads and business analyst, the full project team is assigned once the contract is signed. It means that a key role for the project manager in this phase is to build up the team, assign work, ensure knowledge is transferred from the sales team to the delivery team.

deliverables: – revised solution design (high level design) – clarified requirements – detailed design

miltestones: – detailed design agreed

D2 – Build
The completion of the build phase is when all software and hardware are created/built. This can be hardware build, custom development, specific configuration set-up. The key outputs are the physical components for the hardware and software and associated documentation.
Together with the build comes unit testing of each of the components, individually.
In this phase we also build the tests plan and instruction that we will use in the next phase.

deliverables: – hardware and software components – unit tested – hardware and software documentation – unit test instructions and results – factory acceptance tests plan and instructions

miletestones: – unit tests completed

D3-Verify
Internal verification that the build delivers what it should be. The tests in this phase are about making sure the solution as one is working – that’s factory acceptance testing, in the previous phase we did focus more on testing individual components. Here the focus is on the bigger picture. Note that this is not compatible with using a more “agile” and less “waterfall” approach, the gates are not necessary organised in a strict waterfall model, for example here the Verify phase can start even if the Build phase has not completed.
This phase also includes rework activities should the solution be found not to be inline with the requirements.
Upon completion the system is ready for customer validation, which means that the system is ready for shipment.

In this phase we also build the tests plan and instruction that we will use in the next phase.

deliverables: – factory acceptance test results – shipment plan and associated documents – customer acceptance test plan and instructions

miletestones: – shipment

D4-Validate
This phase leads to the acceptance of the solution by the customer, usually called the customer acceptance testing. Could be made up of few different test phases, technical verification, interconnection testing and functional and non-functional acceptance testing.
At the end of this phase the solution is accepted and ready to be “used”.
With this phase the transfer to support should also be initiated and appropriate deliverable created.
Also the migration plan that defines what is next phase about is created.

deliverables: – customer acceptance test results – support book – migration plan

milestones: – accepted solution

D5-Launch
All activities required after the validation phase and before the service is fully launched.
This could be a very swift phase, containing little activities. However it may not be and here are some examples of more complex things to do: – migration of data before service is launched and/or complex activation of service – roll-out of multiple identical platforms on multiple sites (IF this we decide to manage it in this phase and use a single site for the validation)

In any case the main deliverable here is the execution of the migration plan.

deliverables: – go-live report

milestones: – go-live completed

Group: SUPPORT

Support phases are handled by – usually – an other department of the organisation. Their involvement is of extreme importance to ensure the first few weeks after launch are trouble free and when trouble comes that they are managed the way the customer expects them to be managed. Spending time to train the support organisation is then crucial and this is done in the Validate and Launch phases which really means from a support point of view the “Initiate support” phases.

Taking into account that the support has been initiated we only have 2 phase now: – S1- Run – S2- Terminate

S1-Run
This is about fulfilling our support obligations. That phase can be very very very long, could be years!
Activities are focused on: – fixing live issues – applying standard upgrades to the system
That’s about it – I won’t go here into more details of outputs and deliverables.

S2-Terminate
This phase kicks off when support is terminated for whatever reason. It includes all activities necessary to close the maintenance for this solution.

A quick workd on managing end of phases

Each end of phase is a “gate” where associated deliverables are checked for completion and authorisation to go onto the next phase is given by management. End of phases is a time where the management/PMO of the Project Manager should be looking at the project in details. I would even suggest that management really gets involved in the project at the gates stages only UNLESSsignificant deviations from the plan or critical issues are raised during a phase.

At the end of each phases there should be: – a review of the project plan and particularly an update of the next phase plan – a review of the risks and update of the plan to make sure actions are taken for those risks – a review of the project status from a financial, quality and time perspective

Final words

Benefits

A PRD really structures the flow of projects from sales to support. This has a number of direct consequences and benefits that we are summarising here:

- it creates a shared language within the company, so everybody talks about the same thing and communication is greatly eased. – it drives project planning throughout the organisation, as the structure of the plan and key deliverables are dictated by the PRD, this create an environment where standardisation of deliverables is possible which is the basis of process improvements. – it glues together different part of the organisation (sales, operations/project delivery, support) by adopting phases that involves all of them. This is important as the Buyer organisation team is usually more ‘united’ behind the project than the Seller team. – by creating a unique way of planning and thus reporting on the projects it enhanced upper management visibility of the portofolio of projects. – by adopting a common language it facilitates training and coaching of staffs and help build a skilled force.

Impact on the organisation

Implementing a PRD needs top management back-up as it requires, and in this example very much so, different departments to align their processes with an end-to-end process that goes beyond each department responsibility. A PRD requires them the adapt to another way of workingAND also report at each phases to the organisation in a way they did not report before. This could be a significant change.

For example the Win Business second phases rely a lot on resources that normally belongs to the project delivery side of the business (Project management and Solution Architect) – this requires strong alignment between both department to ensure resources are lined-up.

PMO Role

The Program Management Office’s mission in such a context is to create, maintain, communicate the PRD in the organisation: it creates the standard and makes sure it is applied. It also leads the improvement initiative by checking if the standard are met and comparing the standard with the state-of-the-art in the industry.

Another mission is more operational: manage the end of phases reviews, manage the portofolio (if not entirely then maybe only manage its reporting to upper management), possibly manage conflicts in resources and priorities between projects.

Finally I have attached an overview of deliverables and milestones for this example PRD, the end of phase review and the activities per phases.

PRD table