30 June 2007

David I Cleland

Occasionally I publish a post on an influential person from project, information technology, management academia or industries. They are provided as starting points for further reading.

Today’s subject is Dr David I Cleland.

One of his areas of expertise is connecting project management and strategy. That is, how you can best achieve your strategic objectives through projects. It seems fundamental to the task these days, doesn’t it? Once upon a time it was a novel concept.

If you are involved in high end enterprise architecture, strategic planning or even setting up or improving a project office you should read this man’s work. Dr. Cleland is the author or editor of 39 books on project management, engineering management and manufacturing management; he is the most published author of PM textbooks in the world.

Dr Cleland has been so influential that the PMI established the David I. Cleland Project Management Literature Award in 1997 in his honour. The award is given for recognise the best written contribution to the project management industry.

Here are some of the books and papers he has written. Take a tour of his work and be better informed.


26 June 2007

Business Process Repositories

Here is a good introductory article on Business Process Repositories by an expert in the field. I thought it may be interesting reading for those of you about to begin one.

The article goes through what they are, their business benefit, and covers off some design elements and key requirements.

You might also want to visit the BMP institute for a deeper view of the BPM industry.

BPMInstitute.org is a peer-to-peer exchange for business process management professionals and is hosted by BrainStorm a trusted source of unbiased information.

The Value of a Formal Business Process Repository
By Sandra Lusk, PMP, Tuesday June 5, 2007


25 June 2007

PMs and BAs working together

Often the things I post about are triggered by events at work. Sometimes it takes a few months to get around to posting, but generally I am reflecting on lessons I have learned one way or another.

Here‘s a lesson I am happy to say I learned from someone else’s experience. People will lie to you about what is going on in a project. “Everything is fine” they say as another milestone is missed and covered up. You trust the wrong people. And sometimes on a busy project you miss the lies.

There is a lesson in there, and it offers an opportunity to extend an idea from a couple of blog posts from earlier this year.

One of them was by Barbara Carkenord who wrote about why a BA is a valuable partner for a project manager. Read the article here: Why Does a Project Need a Project Manager and a Business Analyst?

Beyond the fundamental differences in the roles' focus there are other benefits. Barbara's focus was on the way the BA is focused on the operational stakeholders and the PM should be focused on the sponsor and strategic stakeholders.

An analogy is the way large corporations have a CEO and a COO. The CEO is focused outwardly on shareholders stakeholders and the press, while the COO is dealing with managing (and often transforming) the day to day operations.

The PM and the BA have to trust each other and work well together. If they do they can share knowledge and warn each other about potential pitfalls and risks. The relationship should be intimate and honest and should be established early in the project while there is time to work through the process of establishing a common language and set of expectations. Two sets of eyes are better than one.

Have you got that relationship on your project?

23 June 2007

The Ipod by Microsoft; a metaphor for project management



Many people have seen this parody of packaging. This clip was produced for Microsoft so they could work with their staff on addressing their marketing processes. I’ve seen and worked in similar processes myself, and so have many of us. That’s why it’s funny.

Watch it again and have a think about how the challenges of project management or requirements management are similar.

I often find myself investing most of my efforts into managing what I consider a technically simple solution through complex organisations. They are complex because you have to find your way through multiple stakeholders agendas, opinions, and views developed over maybe a handful of 10 minute conversations. You know what needs to be done, but you need to convince others along the way.

Often large corporations also have a very stifling, risk averse culture where any one of a dozen people can place constraints or veto ideas and so leadership in thought, design and so on becomes very hard. It's easier for people to say no than yes.

To me this clip highlights that the challenges are almost universal for large companies. It’s up to project professionals to lead the way and argue for good design and to defend them in the face of a conservative and compliance culture.

20 June 2007

Customer facing staff are part of the solution

Do your products suck? In the end it may not make a difference.

Projects are often working hard to deliver new products. What happens when they get to the shop floor (or call centre?) Apparently not many customer facing employees are interested in actually helping customers.

Have a read of this article and think about your change management programme that is going out there with your new product.

In your projects - Are the staff picking the products up and being engaged? Do they want to promote them to customers? Or are you just putting them on the shelf and hoping they will sell themselves?

I was led to this by Tom Peters' blog.

19 June 2007

I am Craig Brown

I have been asked to put a bio together for Fadi El-Eter at PM Hut. He is going to republish a few of my articles from here.

Possibly a few of the regulars at this site might be interested in who I am also so I thought I’d post it up here.

And maybe one of the dozen visitors a day that come looking for insight into Precedence diagrams.

I am Craig Brown.

I have worked as a project manager and business analyst mainly in the Australian ITC, Banking industries. I have also worked in the law, education and welfare industries, including starting a law firm with some lawyerly members of my family.

The most recent after hours/ personal project I am running (with an entrepreneurial former workmate) is a dot.com start-up that I’ll be publishing here eventually.

I have worked on a variety of operations, sales and marketing projects that range from large ones that drag on for years and cost millions but leave everybody disappointed, to short sharp focused ones where everybody walks away a winner. And the ones in between.

It’s easy to say the big ones never work and are too hard, and that you should avoid them where you can, but I have to say; I respect the people that take on the big challenges and have the tenacity and bravery to slog it out over the hard yards.

Persevere was my high school’s motto. I went to university and did a bachelor of business, mainly management and marketing.

I took what I learned and started working in a help desk at an Australian telco supporting its internet, cable and telephony products. I was a troublesome worker because I was always asking questions and suggesting better ways of doing things. Eventually I was shifted into a process improvement team and from there to more projects, consulting and analysis work and so on, all the while trying to maintain a customer/client focus in my work, which has mostly worked...

Two and a half years ago I went back to formal education and began a Masters degree in project management, which is not quite completed. Part of the course required the maintenance of a learning journal. That was the genesis of this blog.

I am currently working with a Melbourne based IT consulting firm called OptimiseIT. If you are looking for work as a PM, BA, or other IT professional, or if you are considering getting into the industry, feel free to get in touch via this site or via the OptimiseIT site.

And thanks for coming by and reading my site.

18 June 2007

Comparing Software Development to Auto-mechanics part 3

What are the similarities between IT project management and a mechanics working on a car. This is the third and last in a series comparing the methods of my mechanic to project management techniques.

You can read the previous entries here.

Build and test

What I do
Not much really. The car is in his yard and he’s working on it. I have agreed to the price and conditions and don’t really expect to hear from him, although I will if something is discovered in during the work that hasn’t already been identified.

For example if there is a problem that is discovered when the car is disassembled I’ll get a call to discuss the change of scope and the potential options and their costs. This would be similar to the change control processes used by projects.

What he does
My mechanic will be doing the work according to his plan. If pieces of work come under his allocated time budget, he’ll accrue them in his contingency – that is; I won’t hear about them unless there is time left over at the end. The same goes for parts.

If things swing the other way they will use up some of the contingency he build up or loaded in at the front of the process. If things really start to blow out I’ll get a call. Given the maturity of the estimating process that is only likely to happen if there are undiscovered problems like those mentioned above.

The test part of the process is similar also. He will test each piece of work as he goes and when completed major components will be tested together. For example once all the engine work is done the engine will be turned over and run for a few minutes. Additionally as all the components are completed the whole car will be tested with a test drive. F he notices any problems he’ll get back under the bonnet and fix them.

How he charges
At this stage I am being charged time and materials, but I have been given a cost estimate that I expect my mechanics to stick to within a certain range, say 15%.

I have opted to take the off peak time i.e. get my work done a little cheaper because I am not asking for it to be ready within a week or two. That means it could be several weeks before the car is ready. I have not worked any arrangement out for this process, although given the maturity of his business, he has indicated about 4-5 weeks as a reasonable time to wait.

Similarities and differences to software
I guess the processes are similar here, especially the change control process.

The key difference seems to be the maturity of the estimating process means that I can be confident in the cost closely matching the estimate. My experience in the past is that usually, but not always, mechanics come in under budget.

Another difference is the mechanic’s ability to act as a user (a driver.) He can test drivethe car and assess, probably better than I can, whether it is fully ready for service.

Here’s hoping.

16 June 2007

Ethics in project management

An interruption to the normal broadcast.

I was just at Seth Godin’s blog where he has posted an article about ethics in marketing.

It got me thinking that you should apply the same principles to your project work. Have you even quit a job or changed a project’s direction because of the ethics involved. Have you thought about your values and how they align with your job?

The PMI has a standard for ethics that you sign up to when you join. Here’s a top level summary.

Member Code of Ethics:
As a professional in the field of project management, PMI members pledge to uphold and abide by the following:
  • I will maintain high standards of integrity and professional conduct
  • I will accept responsibility for my actions
  • I will continually seek to enhance my professional capabilities
  • I will practice with fairness and honesty
  • I will encourage others in the profession to act in an ethical and professional manner

You can (ad should) read the full PMI ethical standards here. But you shouldn't stop there. Ethics extend beyond your professional relationships to your relationship with your community and the world at large.

You should take time to reflect on what your values and ethics are and how they affect your professional decicions. They are yours and you control them and how you applythem, but you should know them.

13 June 2007

Comparing Software Development to Auto-mechanics part 2

My old MG is sick and I have a mechanic on the job. I thought it might be intertesting to compare the mechanic's project management processes to those used in the software/corporate project environment.

In the first post on the topic we have agreed that the work needs to be done, and he has given me a high level cost estimate.

Now, his next step is to give me a detailed analysis of the problem, a more detailed cost estimate and breakdown of the work.

Analysis and design

What I do
Go home and wonder where I’ll come up with the money

What he does
After I agree in general terms to the work being done and that yes I can afford it he tells me his next step is to work out a detailed schedule of work and cost estimate.

He opens the car up and pulls parts of it away. He looks under the bonnet, the chassis and behind the wheels. He then itemises the things that need work and estimates the effort it takes him to do each activity. He then sequences the activities so that the end job will be cheaper – eg by doing all the engine bay work at the one time, so he doesn’t have to pull the engine out more than once.

He broke the work into packages in case I couldn't pay for all of it in one go, and he prioritised the most important (safety) items first.

Eventually he has his first draft of the schedule of work and the costs.

His next step is to check it with an expert – in this case a manual for MG mechanics on how long each task should take (often within a range.)

Lastly he lists contingency items and adds them at the end.

How he charges
This analysis and design work is not charged either, but again it is time boxed and the potential gaps are highlighted in the contingency work.

Similarities and differences to software
Cars have been around for about 100 years and this method of dealing with estimating work has been around for at least 30 – 40 years. Software estimating should really be at this level of maturity, where there isn’t much that is really unknown except for:

  • Constraints to the requirements
  • Integration to legacies
So why is it that every estimation effort seems to be a finger in the air guesstimate?

Lastly, I particularly like the act of checking your estimates against an expert before handing tem up for review.

(There are systems and frameworks out there that can help you improve software development estimates, but not many people seem to be using them.)

Comparing Software Development to Auto-mechanics part 1

My car is with a Mechanic this month. It’s on old car from the 60’s and I like it a lot, but it’s worn out and needs a comprehensive overhaul. My mechanic has quoted me a worst case $4047. Ouch. At least I get to keep driving it.

Let me tell you about how he is running the fix Craig’s car project. I thought it might make for an intersting comparison with software type projects.

I will describe what he is doing under the SLDC stage headings. I am mainly interested in the estimating and cost management aspects of this work and how it is different to how many software projects are managed. I wonder if there are things that can be learned.

Scope and Initial estimates, the business case

What I do
Choose the right service provider. I use the Yellow Pages, Google and referrals. I check with the MG Car club and eventually I find a guy who has a background dealing with old MGs.

What he does
Takes a short look at the car – maybe 20 minutes. He then calls me back with a high level estimate; “It’ll be a big job” and discussed some of the obvious issues. He then tells me that he’ll need to spend two hours on assessing the car and coming up with a full quote. He also takes the time to talk about how he is an expert in this sort of car and he knows what he is doing.

How he charges
He isn’t charging me for the initial feasibility and estimating work, but is time-boxing his efforts and reporting on the degree of uncertainty.

Similarities and differences to Software Development Processes
At this stage they appear very high. It’s all about discovering what you don’t know, picking a strategy and being able to put a scale on the work to be done.

11 June 2007

Joining the project team late

Sometimes you get assigned a project that’s well and truly underway. Sometimes it can be two thirds done. Often they are short term projects – for example a product launch or an event.

As a project manager it’s your job to manage order, structure, quality and risk into these frantic projects, but there is already a team of experienced people doing their specialist thing, and really, you are just going to get in the way.

How do you handle it?

You have the option of standing back and hoping nothing goes wrong. You could also do your documents, circulate them and make sure everyone knows you have done your planning thing. You could even call the project to a halt while you get your planning and work in order. Of course you may not have the option of there is a fixed deadline.

The thing that you should be doing is talking to everyone on the project and finding out what they should be doing, and how they are feeling about their work and the project. You also want to be talking to the key stakeholders.

You are listening for risks.

At the same time you are also looking for structure and competency, dependencies and so on, but mainly it’s risks.

You are going to have to do the integration thing on the fly. Documents can help you analyse and communicate what’s going on but in these fast, in progress scenarios you really need to get yourself across the game.

If there are no major risks to worry about you can get involved in the usual project management things, but your first focus should be on risks.

7 June 2007

Screwing Performance Reviews?

Pawell Brodzinski, an IT project management blogger from Poland, wrote a blog post lamenting annual performance reviews a few weeks ago.

Today I dicoverred an excellent article from the Harvard Business Review (Kohn 1993) proposing that they are counter productive. It's called "Why Incentive Plans Cannot Work" and you can read it here. It's appended by responses from industry experts which gives the whole peice a good all-round point of view.

In my reading I have yet to come across a better summary of the value of incentive based pay. If you are a manager and about to kick off your performance review process I highy recommend reading this article.

I also researched my way to another article called MONSTER - Monitoring Satisfaction To Ensure Retention.

What's neat about this article is that it applies the Kano quality framework to the idea of job performance and reward. As I was reading the Kohn article my mind kept flicking across to the same ideas; that sure money counts, but is more of a basic requirements than a reason to get excited about work.

Better Brainstorming Sessions


“Projects are a series of unfortunate events.”

I love this quote. If anyone can tell me where it came from please leave a comment.

When you deal with projects you are dealing with problems. Not just the problem (or opportunity) that the project sets out to rectify, but the many problems that come up along the way to do with misunderstandings, bad estimates, unexpected discoveries and so on.

Project workers need problem solving tools and one of the most popular is brainstorming. It’s conceptually simple, easy to implement and quick to yield results.

This week the people at Change This published a paper on improving your Brainstorming sessions through better management. If you want to learn more follow the link at the bottom of this post.

Summary: Brainstorming is a powerful tool, if used correctly, but just like any power tool, you must read the manual, follow instructions and use the thing correctly…or you’re wasting time. Randah Taher presents 10 guidelines to optimizing the power of brainstorming.

http://changethis.com/35.04.Brainstorming

4 June 2007

Salary Survey for project workers

MichaelPage publishes a Salary Survey for Australia’s IT industry each year. It has recently been published again.

Salaries range from $65k to $115 for business analysts and $90-150K for project managers. Programme managers can score $180k.

A couple of trends – on average you’ll get less as a business analyst in the banking industry but you will get more as a project manager. You'll also earn more in Sydney, but no surprises there.

The survey also includes other IT and project roles.

Read about it.

Better requirements

Can you imagine running a product development project without knowing what the price will be when you go live?

The people who say yes to this question have probably worked on marketing projects.

Here is an idea for all you people out there working on marketing projects, with marketers or sales people as the primary sources for your project requirements: It’s a quality check on your requirements. It’s ensuring that you are applying value management to your requirements. And it’s about making sure you have properly thought about and configured your product before you sign-off requirements and begin designing or building your solution.

It’s the Marketing P’s.

My web browsing on the subject inclines me to think that the marketing P’s are a bit out of fashion with marketers today, but I put it out there as a simple heuristic we project workers can use to check our requirements specifications against.

I have used this when dealing with marketers and sales people sponsoring projects and it works very well as a framework for them to define their high level requirements. You can then manage your project to a clear agreed outcome that is a well rounded product. Fashionable or not, it is practical and simple.

The method is simple; Simply create a checklist of each of the Marketing Ps and read through your requirements to ensure they sufficiently address the criteria.

I think this method could easily be applied to all projects, not just marketing, because at the end of the day you are creating a product (via I.T. systems, processes or physical production) that people are going to use.

Marketing makes you address the human use part of the problem; does it suit their needs? Is it something they are going to consider helpful or a hindrance? Will it be something they can afford to take on? (Price may not always be money, for example it could be the effort to adopt a new internal system.)

The original 4 Marketing Ps were price, place, product and promotion. An additional 3 were introduced for services marketing to make 7Ps of marketing. These were people, process and physical evidence (sounds like RATER’s tangibles.) You can read more about the Marketing P’s elsewhere to get a deeper understanding of what they mean. Naturally you need to adapt them to fit your local environment.

I invite you to have a look at the project you are working on today and see if all the marketing Ps are addressed, and if not, why not. What implications does this have for your project?

I'd love to hear comments on this topic.