Search This Blog

28 February 2007

Marketing Projects: Do people market projects today?

I investigated whether marketing a project to stakeholders and user groups could improve a project’s chance of success. It turns out that there is not much written on the subject area.

Intuitively it makes sense to me that marketing your new customer management system to sales staff will mean better acceptance by the workforce. And it also seems intuitive that configuring your project scope document around ideas like the marketing mix is a more client centric way of stating your project’s objectives and outcomes that the typical technically focused approach used by most project teams.When you search you will find there are only two types of project marketing out there in the literature, and none of them are to do with the application of marketing principles to make projects more effective.

The types of project marketing that is written about are:

Marketing your professional expertise

You are a professional services form and you manage projects for clients. You market your business like any other services business. You configure your services to meet the demands of the market place and your price yourself to be competitive and profitable. (Cova 2005)

Your project is creating a product for end-user consumers.

This is the closest I could find to marketing your project to stakeholders and user groups. The stakeholders I am referring to are usually staff within an organisation, which has different requirements and options as far as adopting project outcomes. For example customers can very easily ignore your product so you endeavour to cater to their needs. Staff can be instructed to adopt a new system without any alternatives.

This type of project is most commonly found in construction. Even though product engineering and software development also create end user products and services it seems that there is still a gate between the project and end customer which is managed by a product manager or other similar role.

End users are not customers and don’t have the option of ignoring the new system your project delivers, but they do have an impact on your success criteria. If for example your new sales support system is difficult to use, or even simply forced on them without consideration of their needs they will rebel in both subtle and unsubtle ways. They can take longer on orders or pay less attention to detail resulting in more failed or reworked orders. They can make things difficult for up and downstream workers.

Just because the staff are paid to turn up and work on your new system doesn’t mean they will like it and marketing the project to them could be the answer.

In the next couple of posts I’ll look at what marketing is and how marketing principles could be applied to projects. I’ll also look at change, or implementation, management and how it is similar to but different from marketing projects to stakeholders.

Bernard Cova, Robert Salle, (2005) ‘Six key points to merge project marketing into project management’ International Journal of Project Management (Jul 2005) pp 354-359.

27 February 2007

Marketing Projects: How is marketing relevant to projects?

My undergraduate degree was a bachelor of business and I majored in marketing. As a marketing student straight out of school I couldn’t apply the theories I was learning to a corporate workplace, but I could apply them to the various service jobs I held in bars, restaurants and retail. It became a lens I used to look at many social interactions.

Later when I started working on business process and I.T. projects I took my services marketing frameworks with me. These projects included things like implementing workflow and payroll systems, or automating or off-shoring business processes and the like.

I dealt with a dozen or sometimes more stakeholders who work in a head office or maybe a couple of regional offices, but rarely have I been expected to do more than generic ‘announcement’ style communications and basic training for the actual frontline users. These user groups can range in number from several dozen to several thousand.

I have been wondering for a while to what degree the formal and planned application of some marketing principles, and maybe the inclusion and execution of a project marketing plan, could help these projects. I believe that many of the key success factors for projects are similar, if not the same as for businesses.

Out of this belief comes a suspicion that, apart from the finite timeframe of a project, projects could in fact be run on similar principles to businesses; after all businesses are beginning to run themselves via projects (Jugdev, 2004). And even the finiteness of projects is stretching out longer and longer, within the context of corporations’ agendas. For example I have worked in a firm that had two CEO changes and a significant restructure in the time that a strategic IT programme only delivered two of four planned significant change projects. The programme lasted longer than some operational business units.

Over the course of the next few posts I am going to investigate and discuss how the inclusion of marketing principles into project planning and execution could potentially improve project outcomes. I welcome comments!

Sidebar: I have bought Joyce, Nohrita and Robeson’s book “What Really Works” and see their success indicators for business as beliveable and a good breakdown of what should be done to achieve success. Projects are shorter term than organisations, and have some distinct qualities and their success factors are also different, but reading this book I see that there are also many similarities in terms of what success is and how people get there.

Kam Jugdev, (2004) ‘Through the looking glass: Examining Theory Development in Project Management with the Resource-Based view lens’ Project Management Journal (Sep 2004) Vol 35, No 3, pp15-26

Richard Joyce, Nitin Nohrita and Bruce Roberson, (2002) ‘What Really Works: The 4+2 Formula for Sustained Business Success’ Harper Collins Business

23 February 2007

Risk and Decisions making

Scientists have scanned people’s brains when making risk decisions. The bottom line is that while there is great diversity in people’s risk taking behaviour, generally people are more averse to loss than they are in favour of gain through risk taking behaviour.

Read this article on the study and think about the implications this has on project risk management. If people are fundamentally risk averse they are likely to want to maintain the status quo – better the devil you know. How does that affect the way you do your job of managing in changes in an uncertain environment?

My view; It explains much of the risk related behaviour you see from subject matter experts and operations management in less mature organisations. This is the scenario where as soon as a risk comes up people want to close the project.
Risk management methodologies such as those described last month in this blog can manage people through what appears to be their natural bias to an objective appraisal and management of the situation, meaning that problems get the attention they deserve and are not blown out of proportion or trivialised and ignored.

20 February 2007

From the International Legal Technology Association

Lawyers getting in on the act...

Project management is so much more than what is visible at first glance. Typically, we just see the team, tools and pieces to complete the project. What we don't see is the planning, tool selection, communication, mentoring or even the "speed bumps" that got the project this far.

Our authors offer their expertise with tips, techniques and wisdom ranging from effectively communicating with the PM team and stakeholders, to balancing processes and technology in a project portfolio management implementation. Our gratitude goes to them.

In addition, we're very excited to offer the results of ILTA's first-ever project management survey, and we extend our thanks to all who participated.

Project Management Survey, July, 2006

18 February 2007

What is a business analyst?

The IT Toolbox website has a blog called “Trials and Tribulations of a Business Systems Analyst” written by a senior business analyst who shares my enthusiasm for developing the business analyst profession.

It makes for an interesting read, and I support them in their endeavours to promote discussions on the BA role and emerging profession.

I do keep reading things that make me cringe though; not because what they write is trite or wrong, but because they write from the point of view of technologists who have migrated into a Business Analyst and come with a series of expectations and assumptions about how the BA role should fit into the organisation. Come to think of it, many business analysts I know that have come from the operations parts of business (the ‘business’ business analysts) have similar pre-conceptions.

Like a lot of problems in the IT industry the issue seems to be in the definitions. There is clear disagreement about what a business analyst is and what their role is in an organisation (or a project.)

The IIBA considers addressing these foggy concepts as part of its mandate and good luck to them. So far they have this to say:

“A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.”
That's it?

Like many participants in the discussion the author of the Trials and Tribulations blog produces a short list of key things a business analyst does and compares them to another emerging role; the business architect.

I don’t think it’s a bad list but I want to offer my own opinion on the matter.

Presuming that an analyst and architect work in the same domain of how businesses work I think we should take a top down approach and look at the role names;

Analyst; a person who analyses
Architect: a person who plans and designs

It seems simple enough to me (I am simple, after all.)

But then there is the other facets to the business analyst role;
  • Business Systems Analysts
  • Technical Business Analysts
  • Business Process Analysts
  • Senior and Junior Business Analysts
They can all be roles in themselves, or aspects to a role.

I feel this topic expanding as I write it so I’ll wrap up with this;

Project Management is at the point where global competency standards are being discussed, but wherever I have looked it appears no-one has even drafted a definitive list of competencies, skills and responsibilities for business analysts. It’s about time somebody did and if you know of any can you please post a link to them from here.

16 February 2007

The BA Handbook: Cash paid for articles

I have withdrawn the offer of money for articles for two reasons; Firstly no-one has really taken it up, and secondly I am spending my money on a new web venture. It's a web 1.0 venture even! I'll post a link to it on my front page when it goes live.

In the meantime if you want to post to the BA Handbook I would be very appreciative, but I think it needs a champion to chase people and make things happen. Any volunteers?

$50 paid for article contributions to the Business Analysts Handbook.

I am the initiator of the
Business Analysts Handbook on wikia. The site is designed to be a repository of techniques, processes and information resources for business analysts.

I started the site because I often work as a business analyst and with business analysts. Many want more knowledge about their role but don't know where to turn.

2006 was a turning point as many training services, books and organizations arrived with these resources. This Wiki is another part of that mix of services.

My problem (that is; my thing) is that I am passionate about sharing knowledge and this is an area in which I have some. And I feel like I need to facilitate it beyond my time limited efforts allow.

I am offering
AU$50 per month for the best article on something (anything!) to do with business analysts or analysis that is contributed to the Business Analyst Handbook until further notice.

Here is the link:

Contribute today!

(Feel free to make it easier for me to track articles by tagging me with an email or a comment on this post.)

Lastly, there are a couple of conditions;
  • If no articles contributed in a particular month meet my personal quality standards no one gets the cash
  • The money is in Australian Dollars and I'll pay to Paypal accounts or Australian bank accounts only
  • Your article should be subject to one of the creative commons licenses, but at he very least it's mine to reproduce (with credit to the author) wherever I want.
Start writing!

13 February 2007

Software Project Management in 15 Minutes

Part 1

PART ONE - It's late Friday afternoon and you have just been told by your boss that you wil It's late Friday afternoon and you have just been told by your boss that you will be the project manager for a new software development project starting first thing on Monday morning. Congratulations! Now, if only you had taken this project management training... PART ONE.

Part 2

PART TWO - It's late Friday afternoon and you have just been told by your boss that you wil It's late Friday afternoon and you have just been told by your boss that you will be the project manager for a new software development project starting first thing on Monday morning. Congratulations! Now, if only you had taken this project management training...

If you liked the tone of the video you might like Bas' book: Surprise, now you're a software project manager.

Project Risk Management 101

Project Risk Management 101 articles in order.
  1. Introduction to Project Risk Management
  2. Raising Project Risks
  3. Risk Management Systems
  4. Describing (defining) Project Risks
  5. Positive Risks
  6. Assessing Project Risks
  7. Assessing Risk Likelihood
  8. Assessing Risk Impacts
  9. Prioritizing Project Risks
  10. Managing Project Risks
  11. Monitoring Project Risks
  12. Closing Project Risks
  13. Risk Management 101 Roundup
  14. The one minute risk assessment

The last article isn't part of the 101 series but has some comments on weighting risks based on the indstry you are working on, so I thought it was relevant and equally relevant.

I hope you find this information useful. If so please pass the word about this site and maybe even leave a comment.

12 February 2007

Risk Management 101 Roundup

I hope that this series of articles has been useful. It is provided as an introduction to the concepts of project risk management. Don't stop here though. Read more and contribute to the discussion with your thoughts and ideas.

To wrap it up I have decided to map the project risk knowledge area against the other 8 knowledge areas of the PMBOK. My comments are only off the top of my head but I think they are a good place to start thinking about risks.

Risks are there and, as a diligent project worker, the thing you need to be doing is identifying them and working out what to do about them. So I present these to show that there are risks inherent in project management, as well as in the individual project/product configurations out there.

Use them as a launching pad for your own risk analysis.

1. Project Integration Management
The more complex a project is the more likely it will fail through integration. The points of failure to look at are the plan and the people. Has enough time been allocated to planning, have the right people been engaged, and does the project team have the experience and capability to the job well.

2. Project Scope Management
"Scope creep can be managed through change requests, but changes still increase cost and delay the delivery time. And they are insidious, coming in as small incremental changes until the scope has become significantly more challenging and the business case much more marginal. Think about the scope up front; is it achievable (with the people and experience you have.) Is it clearly articulated? Does it align with business strategy? Does everyone get it?"

3. Project Time Management
Have you allowed yourself enough time to plan and do the work? Rushing will cause mistakes and often projects are already expensive enough without having to rework and clean up messes.

4. Project Cost Management
Forecasting cost/effort on software is notoriously difficult. Technology keeps changing and so do the staff. Methods such as agile put the programmers close to the people who define the requirements, but do THEY know what they really want? Projects iteratively improve their estimates, but up front you really have only a vague idea of your costs. How will you manage the uncertainty?

5. Project Quality Management
A key risk here is to know what Quality is. It is much less likely to be number of production defects than the level of customer delight.

6. Project Human Resource Management
It is absolutely critical to have the right team. Take your time on hiring and get the right people. The delay to start-up will pay for itself later when you don't have the same number of schedule delays and scope changes.

7. Project Communications Management
It's almost impossible to not communicate enough on projects, but you can communicate ineffectively. Know your audience and know their needs. Communicate to them, but also listen.

8. Project Procurement Management
Are your suppliers reliable? Have you worked with them before? Did they do a good job? Do they deliver to the letter of the contract or are they looking for a satisfied customer? Have you done due diligence checks on them? Have they got any statements of quality (ISO accreditation, customer testimonials, etc.) And are your project team talking regularly to your suppliers? The written word only goes so far.

11 February 2007

Risk Management 101: Closing project risks

You will close project risks at two places;
  1. When the risk can no longer happen (maybe it already has occurred, or maybe it can no longer occur.)
  2. When the project has closed and there are still open risks.
Typically this second class of risks will be to do with the business operating the new product, system or process. For example, if you release a new CRM there is always a risk of critical system failure which was not there before.

But that is not always the case. Many projects launch their product with some planned or unplanned cleanup work to follow; for example some product documentation will need to be done, or a support process for a particular exception will need to be developed.

Regardless of the type of risk, at the end of the project risks need to be handed over to the responsible operations managers, and it should not come as a surprise to them. If you have managed your risks well through the project process you have informed them of the risks and management plans as you have gone along, and all the better of they have been involved in the identification and management of your project risks.

I am an advocate of a risk handover meeting where you produce all the risks from your projects risk management system and talk your stakeholders through them so that they get a complete and appropriate understanding of the risks they are taking on. You may also be able to hand over some of your project's subject matter expertise in the form of advice on how to handle certain operational risks.

Organisations with high process maturity or an interest in continual improvement often migrate project risk registers into larger databases so that future projects can learn from previous experience. For example, if you have had a resource risk on your project (because the labour market is tight or because the company runs to many projects for the number of people) the organisation can learn if you were a one off circumstance or if there is a systematic problem that needs addressing.

9 February 2007

Risk Management 101: Monitor your risks

Risk monitoring should be ongoing and continual. As you travel through the project lifecycle you should be monitoring for changes in the environment and regularly recheck your assumptions. The likelihood and impact of risks changes over time.

Early on in the project the likelihood of risks occurring is much greater due to the relative uncertainty compared to the end of a project. Also the impact of risks changes over time; for example if you cancel s project at the beginning you have expended less labour costs that at the end.

A project’s success factors change over time also. For example a building development may acquire a success factor of dealing successfully with local anti-development protestors. The risks associated with dealing with these stakeholders will change as their importance and influence changes.

As well as monitoring existing risks you will have the opportunity to monitor for new risks. Have new opportunities for risk come up as a result of changing environment or scope? Has the project’s business case or relationship with the rest of the world changed?

Specific things you can do to help monitor risks include:
  • Risk Owners: Ensure all risks have an owner, even if there is no active management plan for them. It is best if these risk owners will have to deal with the results of the risk occurring to give them motivation to pay attention.
  • Risk Meetings: Have formal risk review meetings where people have time to stop and think about risks. Time may cost money but often risks can be much more expensive that they first appear. You can also schedule low likelihood and impact risks to future dates.
  • Triggers: Identify triggers for reviewing risks. If a risk is minor today but will become important if something occurs, look out for the something.

6 February 2007

Risk Management 101: Manage a risk

Once risks are understood and prioritised for action the team needs to determine what sort of action is appropriate? Typical responses to risks are avoidance, transference, mitigation, and acceptance. Each of these responses has certain characteristics and is appropriate to certain types of risks.

Avoid the risk by removing the potential risk through taking precautionary measures, which at extremes can mean cancelling the project.

Usually this means insuring against a risk occurring, but can also include getting the business owner/sponsor to take accountability for the risk outside the scope of the project.

This means minimise the damage a risk can cause or reduce its likelihood of occurring (or both) through taking precautionary actions.

In cases where the risk is considered unworthy of effort to manage it can be accepted. This may occur in instances where the risk is so unlikely to occur as to not warrant attention, or where the impact is insignificant in the content of the business and project’s environment.

Whichever option you pick for your risks you should have a detailed action plan against the risk which includes

  • Who is responsible for managing the risk
  • What is going to be done to manage the risk
  • When are the major work activities to manage the risk going to start and end
  • How the risk will be managed as a result of this management plan – that is the planned outcomes of the risk management plan

For risks that require major bodies of work to be managed appropriately you should consider raising a change request and revising the project management plan to include new or modified work packages including this new work.

4 February 2007

Risk Management 101: Risk Assessment and Prioritisation

Prioritisation is a tool to communicate and agree on what risks are to be actioned most urgently. It sets expectations and allows for people to understand where a particular risk falls in the project’s workload.

If there is disagreements about priorities the likelihood and impacts can be revisited, and maybe a risk can be re-prioritised. This is likely in many projects as the uncertainty of the future diminishes and the likelihood of risk events occurring is better understood.

The diagram below is a typical tool for representing a project’s risks at a strategic level. You may identify several dozen risks and the number of risks (or the risk reference numbers) can be listed in the boxes representing each likelihood/impact assessment. This then gives an overview of the risk profile of the project.
It also highlights which things are priorties to be dealt with.

2 February 2007

Risk Management 101: Assessing Project Risk Impacts

The Impact of a risk may be to the project and its success criteria (eg budget and timeframes or the quality of the project output) or it could be to the business as a result of the way the project is carried out, or even by bringing in a new product.

If you launch a new product there are always risks. These include risks that you won’t achieve sales targets, risks that customer complaints will go up, and risks that regulatory and compliance requirements may be introduced that increase forecast operational expenses. (Risks can also be positive.)

The easiest risk impacts on project performance to measure are impact to project time and schedule, and to some degree quality, through compliance with requirements, but how do you measure customer satisfaction or company brand or some of the other more long term and strategic impacts?

Impact assessments, like likelihood estimates, are often classified into tiers. As a demonstration of the types of impacts I have created a sample table below with more than just financial impacts. It includes impacts such as shareholder value, reputation and regulatory compliance.

There are many more types of impacts as well and you can look to your industry to come up with typical examples. Health and Safety and environmental impact are two popular categories.

However you categorise risks your team doesn’t have to restrict themselves to the list. Just because my table doesn’t address environmental risks doesn’t mean we shouldn’t consider the risk unexpected disposal costs as a result of the type of batteries e install into our computers we manufacture.

Like most things I have been describing here, these assessment tables are primarily guidelines and communications tools. The aim is to inform people what the impact of risks are so that they can be properly prioritised and managed.

Assessments are best done in groups or in an iterative process to normalise estimates. Regular project risk meetings can provide an opportunity for a consensus assessment of risks. An alternative (and possibly better) approach is to have an expert on (or near) the project team who liaises with the appropriate subject matter experts on the risk metrics.

All sorts of rules and processes can be developed to reduce the impact of personal interpretation but in my opinion the best guideline for risk assessment is breadth of experience and deep local subject matter expertise. An adjunct, but an important one, to this is reading up on the risk areas in your industry so you can be informed beyond your personal experience.

Once the likelihood and impact are understood the risk can be prioritised according to its importance. Prioritisation is a necessity as it’s unlikely that the project will have the resources to deal with all potential risks, nor would it want to if the gates are open for SMEs to suggest all risks that occur to them.

Closing out this topic; categories and thresholds help people rate risks, which in turn can assist people in prioritising them. Appropriate threshold guidelines complement expertise and research. Them more experience you bring to bear the better your assessment and rating.

1 February 2007

Risk Management 101: Risk Likelihood

An example of Likelihood ratings for project risks may be; Highly unlikely, Unlikely, May happen, Likely and Almost certain

Depending on where you are working you can put likelihood percentages next to these classifications to increase people’s certainty about what they mean. The insurance company
Benfield has published this table in presentations as an example. Your bands can be whatever you want, but they help people allocate things into classes and they help people understand what likelihood means.

As an alternative classification system I present this one from Southern Cross University’s website:

These definitions can also be enhanced by putting timeframes on them; such as within the project lifecycle, within the benefits extraction period, within a year, ten years etc. Again; it’s all in aide of effective communication.

The Insurance industry uses historical information and sophisticated models to work out how likely you are to be robbed or die of a heart attack. IT and Business projects are not yet at this stage of sophistication and I am not qualified to speak for the building industry. However, there are many reports and studies published on the internet and elsewhere that show common risks and how frequently they occur. And the number of reports increases each month.

You can also look at corporate archives to see what common risks occur where you work. For example is there a risk the deadline is too close and you don’t have time to deliver good quality? Are you the hundredth project in that circumstance where you work?

At the end of the day most people today rely upon their personal experience to assess likelihood of a risk eventuating. You should use yours too, but be aware of its limitations. When you get the chance you can search the internet, your companies documents, your colleagues memories and other places for common risk factors and their likelihood of occurring. The wisdom of many can do a great deal to help you avoid risk.