PMinFOCUS

(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

The triple constraints of Scope, Budget and Time is widely used in project management practices, trainings and publications. The “iron triangle” showing the 3 constraints together (with sometimes Quality or Customer satisfaction in the middle) – with the explanation that if one of the constraint is moving then the other are very likely to be impacted – became a reference in the profession.

Project manager job advertised will ask for PMs able to manage those constraints. Candidate are usually used to this as well.

But things are changing. The triple constraints has officially been enhanced in the latest version ofPMBOK (4th edition, page 6). Now the competing constraints include BUT are not limited to: scope, quality, schedule/time, budget, resources and risks. So other constraints could be considered such as customer / stakeholders satisfaction, environmental impact, etc…In other words the triangle is obsolete.

This is the acknowledgement that a project’s environment is complex and subject to many internal and external constraints, this has become visible with the expansion of virtual teams, outsourcing, off-shoring, public concerns about the environment, real-time information and all those factors that are forcing organisation to be more adaptable and more in contact with its environment. What it means for projects is that they operate with more and more constraints.

Human Resources: projects are fighting against each other for human resources shared across projects. At the same time, effort spent on project are monitored more closely and charged to the project. Project managers have therefore to consider the HR constraints with a lot more care.

Quality: with the growth of outsourcing and externalisation, more and more projects involve buyer-supplier relationship. This means that often “quality” is contractually defined, mandatory to deliver. The importance of quality has therefore increased dramatically for project managers.

Risks: sources of risks are increasing, there are more technology risks, risks linked to the complexity of the project teams relationships is increasing as the number of different organisations involved in a same project is increasing, market risks are changing with product development length being reduced.

Tolerance

With every project I start I always ask the sponsors “where is the tolerance?”, they always look baffled. The tolerance is basically deciding, if something goes wrong, what constraints is the most flexible: do I change the scope to meet the time commitment? do stick to the scope and allow some slippage? if I have to stick to the budget then shall I remove some of the scope?

Understanding the tolerance gives the project team so strong indication about the project’s environment and priorities. I found that this is extremely important to focus the team.

One way to visually represents the tolerance and constraints to use a Radar chart with a scale of your own (in our example 0 to 6). The higher the number the more important the constraints. In order example Budget and Resources are set to 6 so it will be hard to change them (upwards of course), Risks are at 6 as well, meaning that trying to not mitigate risks is not an option. On the contrary Quality has a low number, meaning that if the quality of the end product suffers then it’s “OK” (not sure if that’s a real life example!).

I had a couple of “Twitter” discussions recently about agile vs. ‘traditional’ approach to project management. Traditional means Waterfall for most people (including me), at least in IT.

One of the discussion was about using Agile with Fixed Price contracts.

Usually Fixed Price contracts means that all requirements are known upfront and that a plan is carefully developed from day 1 to project closure in order to make sure all costs are understood, and that total project length is figured out (both to plan resources needs and to avoid late penalties).

Fixed Price contracts also usually operate under a tight Change Control mode, and Changes are not usually welcomed: they disturb the work currently being done by the teams, indeed, the current plan does not contain time to analyse change requests which therefore could be seen as a threat to the execution of the project. One the other hand the customer knows that changes usually means good margins for the supplier.

This tends to go against some of the agile principles about welcoming changes and iterative planning with re-assessment of the scope and priorities at each iteration (for Scrum anyway), also fixed price projects are ruled by the “Contract” and not the “Customer collaboration”.

However this is not impossible and I could find a number of positive experiences (or seemingly).
In this post it is argued that fixed price contracts have better outcome with Agile practices.

I won’t pretend to know the “Final answer”, I am only keen to contribute to the debate. My experience and my observation of the industry I am in: essentially Systems integration for Telecoms operators tells me that there are two hard facts that are HUGE blockers to using Agile for Fixed Price contracts in my industry:

Blocker 1: The project is driven by the contract and both parties are focusing on “what’s in their” for them in the contract. This is the hard reality, a requirement is a requirement, a date is a date.

Blocker 2: The buyer is NEVER organised to cope with Agile techniques of continuous integration, continuous testing. Go and ask a Telecom operator to put something live every say one month over a period of 6-9 months and ask them to validate the deliverables throughout the project. This will (almost) NEVER happen due to all live operational constraints, test environments availability, resources availability.

Blocker 2 is, in my industry, the key blocker for using Agile.

Thoughts?

I passed my PMP certification with PMBOK® Version 3. One of the frustrations I had with it was Project Scope management knowledge area that was essentially focusing on the Project Scope and not the Product scope. The product scope was acknoledged but still not the purpose of the knowledge area, “This chapter focuses on the processes used to manage the project scope.” (page 104).

I felt we were then taken from project initiation to scoping the work to be done without having a process to capture the product requirements. Somehow it was left as a “lifecycle” decision and loosely documented in the body of knowledge.

The figure below is a summary of how scope is defined in PMBOK® Version 3.

PMBOK® version 4 comes with a number of changes and clarifications about scope management. I am glad that some of the changes addressed my frustrations. The figure below is a summary of scope in PMBOK® Version 4.

So here are the changes:

• There is a new input to the “Develop project charter” process: Business Case. Prince 2 people will be happy as Business Case is pervasive in Prince 2 and only briefly mentioned in PMBOK® Version 3 (note: it’s not because it was only briefly mentioned that it’s not necessary to review the business case throughout the life of the project).
• “Collect Requirements” is a new planned activity in Project Scope Management. It outputs the Requirements documentation. The goal of this new process is find out from the stakeholders the project requirements to be met so that the project will meet its objectives. Stakeholders identification is the purpose of a new process as well: Identify Stakeholders.
• “Develop preliminary scope statement” has been removed – it was seen as delivering similar output that what is found in the project charter.
• “Define Scope” has changed: it takes the Requirements documentation as input and its name has been normalised. The output is the same: project scope statement.

To me the major change is in Define Scope. In version 3, it “develops a details project scope statement”, in version 4, it “develops a detailed description of the project and scope”. The emphasis on the product scope is stronger in Version 4 than in Version 3. In Version 3 the message is to focus on the project scope even though Product Analysis is a Tool and Technique of Scope Definition and Product Scope description part of the Project Scope statement. I always thought that there was an ambiguity about product scope: on one hand it was stated that this was not the focus of the process and on another hand we are given the tools and techniques and output.

With this new emphasis on Product Scope and the addition of the Collect Requirements process PMBOK® Version 4 brings more formalism in product requirements capture and definition as part of the project management processes. Good news!

PMBOK® is a registered trademark of PMI (Project Management Institute)

All too often organisations selling IT solutions ignore the role of project management up until the deal is done and the project is starting. In fact, up until it is too late. Organisation are focused on selling products and licences and ignoring – because it is complex and outside the confort zone of sales department – the integration complexity that would need the inputs of a project manager. Project management is expensive and the pre-sales budget is often not big enough to support this cost.

Amongst the impact of this non-involvement are:

• Missing or wrongly evaluated integration activities
• Incorrect dependencies between activities
• Little (if none) check on resources availability
• Missed scope
• Very difficult start of the project – as the knowledge transfer is delayed until the contract is signed
• Bad customer satisfaction
• Incorrect project budget…very likely overspending

This results in a project that starts on the wrong foot and very often means that the delivery will not match the success criteria established. I always suggest an earlier involvement from project management and a better connection between pre-sales and operations processes.

1. Earlier involvement from Project Management

With a PM embarked in the pre-sales activities (read: not full time, just “as needed”, meaning if the opportunity has been qualified as “complex” and requiring the inputs of a PM) the integration requirements will be reviewed by an subject matter expert, this will ensure that the scope of the integration work is analysed correctly giving the benefits of better work packages estimation, better resources needs estimation, better scheduling. This will massively de-risk the project.

2. Better connection between pre-sales and operations processes

Both do not have to be completly separated. During pre-sales some project work can already be started for example to clarify / validate technical aspects, validate project planning. This is ignored more often than one could think! You’d be surprised. At least the pre-sales should generate the following:

• First version of the Project management plan. Describing milestones up the end of the project (those things are contractual) and detailed planning for the first phases of the project (requirements / design for example), describing the complete set of deliverables, assumptions, constraints and dependencies. The rule here is to use a standard project management plan and decide which section should be described during pre-sales. For example if the human resources skills needed is going to be an issue then it should be explored in more details at this stage.
• Acceptance plan and criteria. They are usually contractual items – so all inputs should already be there
• High-level design of the solution: to remove misunderstanding, validate some design options…it is in fact the result of the engagement of the technical department on the project. It’s good at this stage. This is best done when there an agreed interaction between pre-sales and operational processes. When the flow from one to an other is natural and agreed. This way the same language is used and both departments (sales, operations) AND the customer will be better off.