Make your PMO more relevant

Now that the initial PMO wave of enthusiasm has waned, it’s time to drive value through your PMO and make your team more relevant to the organisation.

Take some pragmatic steps:

1. Identify specific gaps per project (or subproject) in your current portfolio
2. Who is not delivering? Why are they failing? Insufficient resources? Underestimated effort, duration, scope or complexity?
3. Provide staff to the project teams to assist in helping projects to fill the gaps – and not just fault find.

In all likelihood the already know the gaps but can’t prioritize sufficiently to address them. Or they may simply not view them with any importance – in which case you can give specific advice on what it will mean to not fill the gaps:

DON’T say: “If you don’t fill this gap, you will fail the next audit/review

They’re unlikely to care and are probably more interested in surviving to the next milestone and keeping fingers crossed they won’t be cancelled.

DO say: “We can help tighten the scope and remove unnecessary overlap with project Y”

They’ll jump at this sort of assistance.  Practical, timely, and visible.

Try to sell them on:

1. Reduce cost
2. Improve scope delivery on time
3. Improve quality of what is delivered

Which of these are important to your team?  All of them?  Then which is the MOST important?  Then target your activities and suggestions based on that.

If you are just a glorified post box and just summarise what other people give you, you may not be around for long…

ACTION

Tomorrow, ask one team member from each project what is their most significant problems and what you can do to assist.

Build better templates and improve your life

A bold statement? Perhaps. But if you use effective templates in your projects and operational activities, you can save hours of work each week.  And who couldn’t use a few free hours each week?

Most templates are set up with the best of intentions.  Two scenarios account for most template libraries – and both tend to wane.

Scenario 1 - Organic – one or two people wrote some cool documents and shared them with some of their team members.  This then spreads to a couple of projects.  But then Corporate got wind of the activity and wanted to turn it into a project with a structured, overly prescriptive database or intranet site (maybe some customer html, CMS, or even Sharepoint).  It then often loses relevance to the coal-face staff since the tool now “kind of gets in the way”.

Scenario 2 – KMS – A knowledge management tool is approved by an executive or similar person who has seen or heard about it and that other companies who set up the tools saved lots of money and drastically improved productivity.  This scenario often has a similar fate as scenario 1 and is doomed from the start.

What can we do?

1. Forget about sophisticated knowledge management systems – they’ll just discourage staff from using the templates
2. Ask individual team members what they struggle with and where they need the most assistance
3. Drop the rest of your existing templates into a sub-page or library so they’re not in the way
4. Review with typical authors what issues they have with the templates and whether it would help to include explanatory text, example text and/or tailoring guidance (what is mandatory and optional)
5. Build a simple page for the templates – that can be accessed with one click and includes only those templates that are regularly used (by the way don’t use webpage counters to determine use – because it often doesn’t bear any relation to reality (unless it equals 0))
6. Broadcast the page to everyone once a month for 6 months and ask people to critique the documents and page.  Tell them to use it or lose it.
7. After 3 months ask around to see if it actually helps

Save your time – build your business.

Do you really need a Project Management Office? (PMO effectiveness metrics)

Why do you have a Project Management Office? What do they do? What value do they add to the company?  Is that their opinion or the business’?

If you have a clear definition of your PMO, go and ask some staff from different team around the company.  Not just project team members but also operational staff.  Are the descriptions consistent? Or do they just provide a generic/textbook description of a PMO.

• Do they provide an example or two of how the PMO has helped?
• Do they describe problems that the PMO has helped overcome?
• Do they mention individuals by name or do they just talk about “those PMO people”?

Take a few simple measures:

1. How much time are the PMO members away from their desks and in the business?
2. How many issues do they address?
3. How many documents have they helped people write/interpret/understand over the past 6 months?
4. How many deliverable peer reviews have they conducted?
5. How often do they provide project insights that are used by the business?
6. How many trends have they analysed in the past two months?  Were any decision made based on the info?

If the PMO just collect and report data, figure out a way to improve their value or just outsource the function.

Rather than a mission or charter, many companies talk a leaf out of the ITIL service catalog approach and prepare a catalog of PMO services that are then offered to the business.  The very act of preparing this catalog will force the PMO and the company to clearly define the purpose and role of the PMO.

Do you have a list or catalog of PMO services listed on your intranet (some mandatory and some optional)? If not, how do staff and projects know what specific activities are provided by the PMO?

If no one ever takes the optional , then either change or drop them and focus on services the business wants to actually use.

How to measure software quality – Starting out

Process quality has been very popular over the past two decades.  From CMM and ISO9001 to 6 sigma, Lean, BPM & beyond we have seen a large body of work produced on the premise that “the quality of the process largely determines the quality of the product”.

All of the models, methods and techniques used for improvement are based on this process-improvement concept.

But are we building the right quality?

What do people mean when they ask, nay demand, high quality products?  More often than not they mention “relatively free from defects” or “great functionality”.  And that’s where the majority of projects leave it.

For software, there is a standard model defined for product quality – ISO9126 (and it’s subsequent derivations).  It provides a set of characteristics which can enable the definition and assessment of various quality attributes of a software product.

Whilst the standard itself is still relatively unknown, most people are familiar with the concepts contained in it – the ‘ilities’:

• Functionality
• Reliability
• Usability
• Efficiency
• Maintainability
• Portability

And each of these is then broken down into more specific attributes.

Yet familiar as people might be with these concepts, they are generally not used – except in a binary sense (important or not e.g. portability not important in an embedded system).

The difficulty faced by most engineers is threefold:

1. the metrics and indicators used to specify and assess the ‘ilities’ are generally not known
2. the characteristics are specified in a generic manner and don’t really provide practical examples are how they can be applied
3. they were created when procedural languages and transaction based systems were the focus – web and mobile based computing was not yet on the scene

So how do we improve?

By identifying 2 or 3 ‘ilities’ that are important to the project – we all know what they are intuitively – and then agreeing on some metrics and targets that provide a benchmark to assess product performance.

The ‘ilities’ are sometimes included in projects as non-functional requirements, but even then it is often not measured using metrics and is more qualitative e.g. “the system needs to be maintainable vrs the maintainability metric to be used is cyclomatic complexity and coherence index is to not exceed 15”.

This also makes it easier for developers to plan their design and test their code.  It also enables users to perform UAT and BRT more effectively.  Since the targets are quantified, you don’t receive comments like:

“hmmm…that seems ok, but maybe it could be a *bit* more maintainable”  

A Federated Process Model

A common problem experienced by companies with diverse operations is that of standardizing processes.

Finding a balance is a complex activity that involves:

a)      having enough processes definition to drive end to end processes and hence results for the company

b)      enough tolerance for variations between departments/functions that that appropriate differing approaches can be taken

Having a federated model of processes enables this balance – so that a standard end to end processes is used (for inputs, outputs, required standards) but function specific variations can be incorporated.

For example if we have an end to end process for development and ops, we may want to utilize Agile or CMMI for systems and software development, 6 Sigma for manufacturing, ITIL for operations.  We can define the workflow at a level that defines the inputs and outputs for each major area/function but leaves the method for satisfying the end to end process requirements to each area/function team.

Each of the areas need to work in unison to deliver the product, service & objectives of the company.  Yet human beings are the resource behind most workflows.  And we is try to enforce procedures that are standardized across the company, but are not necessarily perceived as relevant or appropriate, you’re going to get pushback if not outright rejection.

Processes are to help the company build and deliver on its objectives – not necessarily to get a perfect enterprise process architectural implementation.

An example that I often use is that of road rules.  Yes, everyone has been trained in the rules of the road.  But why do we need to police them?  Because people still break them.  So why do we think we can perfectly define procedures to an incredible level of detail and expect people to follow them?  Nice in a perfect world, but perfect is the enemy of good-enough…

Manage Your Portfolio of Problems Part 1

Does your team and organization suffer from numerous problems and issues?  Do more issues crop up each time you try to solve something?

Managing your problems as a portfolio may help you.

One of the keys to improving your team and organization is to identify and understand your problems.  Another key is to prioritize and solve the right ones.

We’ve all seen the need for recording lessons learnt on projects. The premise is that we’ll see what has happened before and change what we can improve what we do.  There are a plethora of knowledge management systems on the market and in use on projects that enable recording, retrieving and disseminating lessons learnt.  (though the level of use of these tools varies greatly – that’s another story!)

In addition to good practices, we often record problems, issues and risks that eventuated in projects.  We record both the good and the bad in the knowledge management systems.

What is often NOT done is to analyze problems on an organization-wide basis.  This misses the problems that occur repeatedly.  The lessons learnt knowledge management systems tend to be snapshot oriented and do not lend themselves easily to longer-term and endemic problems.  When organization-wide problems are identified, they are normally a bugbear of someone who keeps experiencing the problem (though they may not be able to solve the problem themselves).  It is normally not the result of systematic analysis.

Of course this is one area where QA staff (via process audits and QA process reviews) can help.  By looking at processes that may be enacted by several projects, QA may be able to identify problems that cross projects and teams.

But QA is normally unaffordable in smaller companies.  Even in larger companies they are spread pretty thin on the ground.

A solution to this problem can be to use either:

1. management system review; or
2. executive management team meeting

to review organizational problems on a quarterly or six-monthly basis.

By making it the EMT/ELT’s responsibility (and preferably one person responsible for organizing it) you can get important problems brought to the attention of senior staff.

Simply delegating to junior/operational staff that they need to figure out a solution completely misses the point.  Executives and senior staff are the key to understanding important organizational issues and determining potential solutions.

That’s the when.

The how is in Part 2.

Managing Suppliers Effectively to Deliver Your Project Objectives – Quality and Assessment

I was recently asked about an effective method to manage multiple suppliers on a project.  The client had a number of potential suppliers to engage and wanted to know the best approach to ensure the suppliers deliver what was required.

Answer – each company has its own special circumstances and so each need to adapt their approach to suit their needs…

However… one approach was to make sure that part of the contract included the need to establish the method of providing quality control and assurance on the delivered products and services.

There are a number of activities required:

1. determine the products/services areas and issues that are critical to the project.  If you’re not sure, these tend to be the most complex, unknown, or time critical deliverables.
2. specify the required quality for each of the products and services.  This often takes the form of Acceptance Criteria.  The ‘criteria’ need to include more than just ‘a working product’ in their definition.  It should also include defect levels and any other non-functional requirements together with the measures needed to assess levels of conformance.
3. Identify the quality control (tests, etc) and quality assurance activities for the deliverables.
4. Ensure a mechanism is included to address product and process non-conformance.  Problems occur even on the best projects and they need to be managed as part of the normal project activities
5. Mandate the need for an examination of the key customer processes (management systems, quality systems, Policies & Procedures) to ensure that the capability is there.  Don’t rely on ISO9001 auditors doing this work for you – the process review that you undertaken needs to be specific

Doing this upfront work enables you to build confidence in the project as we have

a)      identified the need for products and services of an acceptable quality

b)      determined that the supplier can deliver

c)      put processes in place (in the contract or PMP or Quality Plan) that will provide QA/QC guidance throughout the project,

and

d)      built an expectation that when a problem occurs, the standard project activities are in place to manage the problems to a successful outcome for the project.

By having these processes in place, you will not have to resort to ‘escalation’ whenever something goes wrong…

Preparing for a Project Sponsor Meeting

Sponsors are critical to almost all projects.  They’re the people who get budgets approved, they’re the ones who provide the energy and impetus for getting the business ready for the project.

Yet PMs often seem to treat them like they’re a pain in the backside and are really just a distraction from the real project work.  When we meet with sponsors, we’ll often take along a project progress/status report and run through it with then during the meeting.  If we don’t have much to report, we’ll often wordsmith the report to make it look like there’s real action happening.  These types of status reports often don’t have many quantitative measures and are a talkfest rather than a real progress report.

However, when you treat the sponsor meeting as the opportunity that they are, you’ll find more engagement and more success in your projects.

Remember that sponsors themselves usually report to someone (or a board, executive team etc) so it’s in their interest to know what is truly happening.

Treat each sponsor meeting as if you were selling them the project/product and you’ll soon see a revitalizing of the business.

Prepare for the meeting by gathering not just the progress report but also what is not contained in the progress report.

Info on the team, the environment, customer politics, project performance enables a much broader picture of what is happening and more of what sponsors really want to know.

They can always read a status report to get the % schedule complete, budget expended, risks identified.  But some PMs exclaim “but we need to explain the report to the sponsor”.  That really just indicates a poorly written report.

Motivated sponsors as just as interested in what is not in the report and most importantly if their expectations are still being met.  They also want to make sure they are aware of any surprises as soon as they crop up – rather than being informed at the end of the month.

An important job of the PM is managing expectations – particularly those of the customer and of the sponsor.  By getting to know their concerns BEFORE the meeting, you can begin to anticipate what questions they’ll ask during the meeting. *

*emails you get throughout the week from the sponsor are a good indicator of their concerns – read between the lines.

Of course if you don’t get anything from them, either:

a)      they’re priorities are elsewhere and you have got to get back under their noses for a successful outcome – “not in their lot, oft forgot”

or

b)      they’re completely happy with progress (less likely)

When you can anticipate their needs and come prepared with answers, you build confidence in their project and your progress.

Here’s a checklist I prepared earlier

Not to sound like a cliche, but help them help you…

Improve project efficiency and effectiveness by dealing with quality part 2

OK, so once you have defined the quality activities required for each deliverable, you are now in a position to start identifying quality requirements for the deliverables – hardware, software, documents, scripts.

This is where many projects really fall down – of those that made it this far

I’ve written about ISO9126 before, but it’s important to start off with just the basics and build a foundation.  This includes both customer and staff expectations.

It’s really an education process – making sure everyone has a common understanding of the quality activities and how to define and use quality requirements.

ISO9126 defines many potential attributes and when projects try to use it they often attempt to use all of them (the ‘ilities’).

But defining them all without having the process and quality infrastructure in place, you end up with:

a)      a mess that no one understands

b)      a complex specification that no one understands or cares about

c)      a mess that causes chaos during scoping, testing and more

So instead, just define a few quality requirements for your most critical deliverables.

e.g.

Software – reporting module                 0 level 1 defects, <15 level 2 defects

Document – specification                      0 level 1 defects, < 20 level 2 defects

But you might say “whoa! Defects remaining in the specification? Are you crazy?!”

Well, no.  In many projects we may not have time to get all known defects corrected – particularly if they’re not vital to the functioning of the product.

Once you have defined these basic defect measures, check with the team, the sponsor, customers and any other stakeholders.  Remember it’s an education process and people are often not used to this.

Once you have defined and agreed the defect levels, ensure that you have the activities and the checks built into the schedule.  No use having defect levels but no tasks or time to manage them.

By the way, remember to define what defect levels mean – a level 2 might be different between a document, script and source code.  Don’t get hung up on severity versus criticality – this is a semantic argument and doesn’t add value to your project.  Just make sure you are consistent in your use.

If you define defect levels as quality requirements, you’ll find a better understanding and gain more visibility into what customers actually want.

We’ll cover more sophisticated quality requirements (e.g. maintainability, understandability) next time.

PS these quality requirements/attributes are often called “non-functional” requirements.

Improve your business with Methodologies, procedures and frameworks

Do you have a methodology in your business? A framework? Procedures? Does it matter?

When methodologies are first deployed there is a flurry of activity where everyone is trained and then set loose upon an unsuspecting world with binders under their arm and a grimace on their face.

There are several things wrong with this picture

1. a methodology is an approach to something but many lack the day to day specific actions and how people are supposed to APPLY it to projects and development in their business
2. Many methods are very lengthy so few people remember most of it after their training – and many often don’t refer back to the method – ever.
3. When staff join the company, they are pointed in the direction of a copy of the method sitting on the shelf and told to read the relevant chapters (though they’re rarely told what these chapters are)

Sound familiar?

One solution is to use procedures for explaining components in the methodology (e.g. risk management, document management, finance, change).  These describe how things are done on a day to day basis.  The methodology is still used as a basis for running projects, development teams, etc.  The procedures are an instantiation of the methodology.

A framework in this case is simply the structure within which you can fit the methodology and procedures.  It provides a context showing how the organization uses methods and procedures to help reach the company’s goals.

A framework is also a good spot to show how the standards and conventions are applied and the reasoning and intent behind the method.

Using procedures within a framework enables us to describe who does what, when and how, and provides a basis for training staff in the procedures relevant to them – rather than having to train them in the entire methodology.  E.g. project scheduling may be of interest to everyone, but finance management may only be relevant to the project manager, sponsor, and finance department.

It’s much easier to run a Finance Management procedure training session than to train them in the whole methodology.  “But can’t we just pick out the finance bits?” I hear you say.  Remember that most methodologies are not modular in their structure.  So using a procedure to extract the finance bits out one time to produce the procedure is infinitely preferable to getting everyone to look through a 100+ page methodology trying to find references to ‘finance’.

Having a 4 page procedure is much friendlier and approachable and is likely to be used.