31 May 2007

LEAN or LAME?

I haven't gotten into methods like Six Sigma or Lean here before but today I came across a Lean Blog with a topical article.

It seems that Lean=Offshoring is a trend in more than one corporation around the world.Mark Graban hosts the Lean blog and laments that Lean (aka Toyota Production System from the 70's) is getting a bad name from companies like IBM who are off-shoring under the Lean efficiency banner.

He has coined the misappropriation of Lean as LAME. "LAME = Lean As Misguidedly Executed, Lean As Mistakenly Executed?Can you think of a better phrase?

Click on over to his blog and add your suggestion.

By the way, if you are a project manager or a business analyst you must know about these systems. Yes, they are faddish, but they are clearly flavour of the month and you need to be able to talk the talk. If you are unfamiliar with the concepts Google them and read up.

30 May 2007

Project Managing the Law

Project management is a knowledge base and skill set that can be applied across many industries. Today only some have embraced it.

The latest to sit up and take note of the benefits that Project Management has to offer seems to be the legal industry.

The push comes from people who work in the legal industry on IT projects, and some lawyers who have a previous career as a project manager of some sort. Most of the information you will find if you search the topic is a dot point on a job description or maybe a sentence on a blog.

Significantly, there is a pull from the industry for project management as well. While the academics and thought leaders don’t seem to have named it yet they are searching for a framework to “pull it all together.” The reason for this is that the legal profession is becoming increasingly more complex.

For a start the amount of legislation is exponentially increasing. Add to this the increasing complexity of international and globalising trade, across multiple jurisdictions, the greater stakes that litigants are playing for and the more complex organisations who are parties to contracts and disputes, and you start to get the picture.

One of project management’s main benefits is its ability to manage complexity and uncertainty and that’s exactly what today’s legal matters are about.

I raise this topic as I heve been a director of a legal practice and we have seen a need for applying project management principles to the work we do. It enables legal practitioners to manage the client through the process more effectively and also yields good results for both us and our clients.

Over the next few months I am doing a thesis looking at how project management is complementary to legal practice management. I will probably publish a number of posts on the topic as I go. I hope you are interested and I hope some lawyers read this and get some useful insights.

Comments, as always, are welcome.

29 May 2007

IIBA event in Australia

The IIBA is holding a series of events on Australia’s east coast in June. They are information and networking events. The keynote topic will be the upcoming IIBA certification exams. It is also a chance to build the organisation’s profile and possibly start thinking about opening chapters in Brisbane and Melbourne.

The events are listed below. You could just turn up, or you could register your interest at their website so they can cater appropriately. The events are free (with free drinks!)


Melbourne
Wednesday 6th June @ 5:30 for 6pm start.
CAE - Level 4, 253 Flinders Lane, Melbourne
Key Note Speaker: Kevin Bourke (Project Smart pty ltd)
Topic: The CBAP Certification and Upcoming Exams

Sydney
Thursday June 7th @ 5:30pm
Cliftons, Level 6/190 George Street
Key Note Speaker: John Katsiris (President IIBA Australia)
Topic: The CBAP Certification and Upcoming Exams

Brisbane
Wednesday June 13th @ 5:30pm
Francis Rush Centre, St Stephens, Cathedral Precinct, Elizabeth St, Brisbane.
Key Note Speaker: Craig Reid (Deloitte)
Workshop: Practical and Interactive session to improve your interview techniques and skills

23 May 2007

The consulting diamond

Are you talking too much?

I keep saying it’s important to keep talking to stakeholders and clients, but what I mean is that you need to keep up the conversation.

This goes for both stakeholder management, requirements management and change management.

There is a time for talking and a time for being quiet and listening. A seasoned consultant shared the idea of the consulting diamond with me recently which elegantly illustrates the point.

At the beginning of an engagement you need to explain what is happening, the reason for the project, the approach and some of the high level objectives. You are doing most of the talking to people who are new to the project.

You then get into a discussion about the stakeholder’s needs, wants, constraints and so on. At this stage you should be asking open questions and letting them do most of the talking. This may go on for one or many sessions.

Eventually you will have gathered enough information and you will close down their talking and get them listening again while you pick up the talk by explaining how their information will be used and the project’s next steps. You’ll continue this over time as you manage their expectations.

Have a think about how you are managing your conversations and make sure you are leaving room for listening.

22 May 2007

An Introduction to Stakeholder Management



The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtual teams, across matrix companies, they may be stakeholders, as their roles extend to beyond the project. They are thus committed more to their local business unit than the project’s success and have an impact on whether the project goes ahead and whether it is considered successful.

When tackling stakeholder management ask yourself what you are trying to achieve with stakeholder management. The bottom line is that you are trying to improve the project's chance of success. And you are doing it through analysing and understanding stakeholder needs, which may become either requirements or constraints, and communicating them effectively back to the project team (and sponsor.)

The cycle of stakeholder engagement
You don’t just do it once, either. Stakeholders needs and priorities are constantly changing as the environment around them changes, and as they learn more about your project. This is especially pertinent to projects that span many months or years.

So, to be effective you need to manage stakeholders cyclically. Here is a four step cycle you could follow when managing stakeholders.

Identify
Who will be impacted? Who are the decision makers in that area and who are the subject matter experts? A good technique to apply to identifying stakeholders is to ask each one you do find to nominate others.

Analyse
What are the impacts? When do they occur? How does the impact affect the stakeholder?

Manage
You need to manage stakeholders’ requirements and manage them through the constraints (time, budget etc.) Make sure their expectations are set appropriately and that you don’t over promise on the solution.

Check
On a regular cycle go back and check with your existing stakeholders whether things have changed. Are there new stakeholders? Have impacts changed? Have priorities changed? The more frequently you are in contact the quicker you will pick these issues up and be able to deal with them.



An aside: I like to model stakeholder and communications plans around the ADKAR framework which drives you to see your stakeholders multiple times anyway, but then you are integrating change management and stakeholder management and that’s a more advanced discussion.

Importance v Supportive
Neville Turbit has an article on the concept of mapping importance and supportiveness. This is a variation on the influence and engagement paradigm. In this model there are two key attributes

  • Importance (influence)
  • Supportive (engaged)

Usually they are mapped into quadrants and you have an action plan for each quadrant. Neville expands the theory and maps it onto circles of importance and supportiveness creating a more tiered effect with room for more flavours of action plans.

Examples;

  • If someone is important but not supportive they are a risk to your project
  • If someone is not supportive but they are not important, they are less risky for the project.



Read more about this stakeholder management framework at Project Perfect.

18 May 2007

Nexus Alpha goes live

This is a message for PM and BA bloggers who come here regularly. (You know who you are and I thank you for your reliability.)

Scott Selhorst at TynerBlain is running an experiement into agile methodology. He has built a web 2.0 thing which is designed to be a respository of project and product management and business analyst articles for you and me; Experts and beginners in the field.

He is currently alpha testing his site and is looking for content owners to donate articles.
  • Go here to donate an article
  • Go here to read about the Agile experiment

And lastly, because it's that kind of day; Goodbye Last.fm and Pandora. You were good while you lasted.




16 May 2007

The shortcomings of the PMBOK and BABOK

If you read the article I linked to in my last post you read that Peter Morris thinks the PMBOK is too limited and that a more holistic framework of managing projects for success is required.

He believes the body of knowledge must go beyond the pure PM techniques and include what is necessary for success for it to be a truly useful PMBOK.

Extending the idea further for business analysts;
Is the IIBA making a mistake by constraining the BABOK to what is unique about the role. Is it unique anyway - see the SWEBOK as an example of overlap. Shouldn't the IIBA work out what the key success criteria are for BAs and make that the foundation of the BABOK?

15 May 2007

What we don’t know about project success

Dr. Peter W.G. Morris argues that the problem with the project management industry is that it's too focused on the tools and techniques of the trade rather than on how projects can improve business success.

He argues that research in the PM industry should be directed towards measures of success, or the processes of defining success for each project. That way the business schools will take more notice of project management in the education and training of business people.

In particular Morris highlights the following:

  • Ensuring that the project’s requirements and objectives are clearly elaborated
  • Defining the relation of the project to the sponsor’s business objectives
  • Developing the project’s strategy
  • Managing the evolution of the proposed technical solutions to the project requirements.

These are all strategic issues for a project. Are project managers guilty of too much micro management? Is there an opportunity or a need for project managers to lift their view from the details?

Potentially this is where the BA becomes a critical part of the project team. the BA is focusing on the detailed design issues, and managing work to milestone deadlines while the PM focuses on the big picture and stakeholder management.

Read the whole of Morris' article here.

14 May 2007

Change Management – the ADKAR framework

Project success relies upon more than just building the right tools and handing them over.

Today project teams are asked to implement a holistic solution to a business problem. This often means the solution is comprised of people, process and technology. As a result there is a significant change management effort that the project team is expected to lead, manage and support.

Project managers often take the phrase Change Management to use in the context of managing scope. Change management is much, much more than scope management and this co-opting of the phrase exhibits the Project industry's prejudice for the hard scientific management approach of the engineering world. Rather, the humanistic view of change management used in social sciences, including management itself is the more useful and appropriate definition for project management.

In the late nineties the ADKAR change management model was developed by Prosci as a process for managing people through organisational change. Prosci recognise that people don’t just take on change when you roll out a new business process or system. In fact their research suggests that failing to effectively manage change is one of the top three reasons for project failure.

ADKAR standards for the five phases people need to be taken on through their change journey. ADKAR stands for Awareness, Desire, Knowledge, Ability and Reinforcement.
  • Awareness of the need to change
  • Desire to participate and support the change
  • Knowledge of how to change (and what the change looks like)
  • Ability to implement the change on a day-to-day basis
  • Reinforcement to keep the change in place

They are outcomes rather than activities, which is useful for integrating it into an outcomes focused project plan.

You can read more about ADKAR at Prosci's Change-Management site.

9 May 2007

Change Management – a definition

Project practitioners everywhere are using the phrase change management in the context of managing the work effort or the design elements of a project. It’s a problem when you want to talk about change management in the holistic context of the change the project is bringing to the client.

Both the PMBOK and the PRICNE2 framework use the phrase change control. This phrase is better as it differentiates it from change management, but still focuses change efforts on managing the scope rather than the project’s efforts to implement change into the client organisation.

Implementing change is where the true focus of change management should be for project teams. Regardless of whether your project is introducing new internal systems or a new product the client organisation needs to be able to adapt to the new systems, tools, processes or structures.

Project management is more than the hard sciences of how to plan, monitor and control a project. Successful people management is one of the critical success factors for a project and so management theory should not be discounted when talking about project management.

Change management in the contact of modern management theory begins with Kurt Lewin’s three step freeze, unfreeze, refreeze paradigm of the 1950’s and has continued to evolve, drawing on psychology, sociology and other social sciences as it’s travelled.

If you want to learn more about change management in the first scope oriented sense try this website. If you want to learn more about the ideas around people change management stick around here.

1 May 2007

Is PRINCE2 better than PMBOK?

Is PRINCE2 better than PMBOK? Max Wideman, former president and chairman on the PMI, has compared these two leading project management frameworks.

His bottom line assessment is that PRINCE2 and the PMBOK suit different purposes. PRINCE2 is a useful guidebook for managing a project. It provides a process and framework to operate a project. The PMBOK is a good framework for learning about projects and provides a foundation for dealing with a diverse range of project types. Both frameworks have assumptions and implications inherent to them that bring particular strengths and weaknesses.

At the end of the day Max suggests they are complementary, and if you have studied (and used) both you will know more than if you have studied (and used) only one.

Max’s article is here – well worth a read for anyone considering Project Management certification.