ah ha moments yearbook 2011

Ah-Ha-Moments Yearbook 2011

By Luis Seabra Coelho, February 2012.

From http://www.ah-ha-moments.net/

http://www.ah-ha-moments.net/


About this Yearbook

This eBook includes all the posts on Ah-Ha-Moments during the year of 2011, the

second year of existence of this blog. The objective of this yearbook is for you to

have an easy way to get to all the information posted on the blog. I hope you find

it useful.

Please use this information as you please. The only thing I ask is to mention its

origin.

To formalize this, all content is under the Creative Commons license:

Ah-Ha-Moments by Luis Seabra Coelho is licensed under a Creative Commons

Attribution 3.0 Unported License.



http://creativecommons.org/licenses/by/3.0/




Articles

Marketing Process for Project Management

And why you need to align (i) how others see your project to (ii) what your

project really is

About marketing

I confess I have a love/hate thing for Marketing. Love the creativity but hate the

attitude. At least the attitude I usually see which is being on your toes and

pretending to be something you're not. You know what I mean, like those

people that can always find a way to say how great they are when in fact they're

not. But...

Seth Godin

...But then I came across an excellent post "The appearance of impropriety" on

Seth Godin's blog where he defined marketing as what others say and think of

you. It seems that the trick has 2 parts:

1. Act considering what others would say of your options (eventually choosing a second best line of action)

2. And so make the image that others have of you to be what you actually are...

Ah ha! So this is marketing! And it does sound a lot different from the "be on

your toes" kind of approach, doesn’t it? This is good and sound marketing, not an

evil and greyish thing.

What about Project Management?

http://sethgodin.typepad.com/seths_blog/2010/12/the-appearance-of-impropriety.html

http://sethgodin.typepad.com/

http://1.bp.blogspot.com/_yRrxfYiMBlo/TSbR_PHD27I/AAAAAAAAAWw/IE1qIEZ7CBc/s1600/Marketing.jpg

http://3.bp.blogspot.com/_yRrxfYiMBlo/TQC7oMo7MfI/AAAAAAAAAUM/XCB6oHtGuOo/s1600/Seth+Godin.jpg


Now in Project Management you have to deal with people, right? And if people

don't see you and your project as they are then you're bound to get in trouble

somewhere along the way. Imagine you're doing a project that will increase the

productivity of a group of people. Imagine also that the project is being done

because that company expects to increase business so much that either they hire

more people or they streamline processes and stuff so their productivity is

increased. If you don't pass this message in every opportunity you have, if you

don't include this in all your communications, then people affected by your

project might start to worry about their jobs; they might even try to sabotage it

and start saying that things won't work if the project is implemented. Now this

example is with people affected by this project's results which are weak

stakeholders in many cases. Imagine if this happens with a stronger stakeholder.

Imagine if it happens with the project sponsor. Have I got your attention already?

Marketing and risks

Alliging (i) what people think of your project to (ii) what your project really is

makes sense.

So why not include marketing on you Project Management needs and worries?

What you really should do is include a Marketing Process mingled with the rest

of your Project Management processes. A Marketing Process?? Sure, and this can

be done in very simple inexpensive ways, depending on the context of each

project - there are simple processes you know? The simplest process that I can

think of is to include a risk on every project, something like the following would

do:

"Stakeholders might misunderstand why this project is being done

because -->root cause<--

and the impact would be -->the impacts<--"

Pretty simple - and inexpensive. With this risk included in every project of yours

you would be able to:

Remember of this potential mismatch

Act accordingly in your particular context

The best part is that it would be inexpensive to start off and you would never fail

a project because you just didn't imagine that this could be a problem – isn’t this

http://2.bp.blogspot.com/_yRrxfYiMBlo/TQZYLZGMezI/AAAAAAAAAUs/djBXPS0bWDs/s1600/projwb2.gif

http://2.bp.blogspot.com/_yRrxfYiMBlo/TSbao0lPyII/AAAAAAAAAW0/ghAEdmpeajQ/s1600/risk.jpg


why we have Risk Management? Bottom line is that you could be turning your

project into a success. So if you include this risk on your projects then...

...then you could be a better project manager!

If you enjoyed this you may also enjoy these related posts:

Meet the most wanted Project Management tool: the dog!

It's all about interests, not positions

Quality is what you do when no one is looking

Is there a need to follow plans?

Filed under the same labels:

Article

Risk

Images from www.mariliaggomes.blogspot.com and aaronlewis.wordpress.com

http://www.ah-ha-moments.net/2010/05/meet-most-wanted-project-management.html

http://www.ah-ha-moments.net/2010/06/its-all-about-interests-not-positions.html

http://www.ah-ha-moments.net/2010/11/quality-is-what-you-do-when-no-one-is.html

http://www.ah-ha-moments.net/2010/12/is-there-need-to-follow-plans.html

http://www.ah-ha-moments.net/search/label/Article

http://www.ah-ha-moments.net/search/label/Risk

http://www.mariliaggomes.blogspot.com/

http://aaronlewis.wordpress.com/


How to solve communication problems

A nonsense approach inspired by the Monty Python

Instructions:

1. Sit comfortably in front of your PC/laptop/iPad or whatever equipment you’re using to access the internet

2. Make sure you’re alone and you will not be interrupted for the next 2:15 at the very least

3. Play this clip and 4. Pay a close attention to everything happening in the video.

Finished the video? Ok, time to stop fooling around and move on to some serious

business. I’m going to present to you a 4 step solution to all and any

communication problem, and all thanks to this sketch. All you have to do is the

following.

Step 1: Accept the fact

It's broken, accept the fact.

On the video, the gentleman reporting a burglary (played by Terry Jones) is a bit

angry at first, kind of offended. But there’s a point where he realizes there’s a

communication problem. Now the policeman (played by John Cleese) doesn’t

give him any hints to what the problem is until the gentleman starts to despair.

They both seem to be unaware that there is a problem.

So the first step to solve communication problems is to believe that there really

is one. If you’re just told there’s a problem you probably won’t accept it, you

have to believe it. Back to the sketch, if he didn't believe it he would probably

find some other root cause for the problem and would never face it.

Step 2: Find a solution

Focus on the problem and not on who’s problem is it. Put yourself on the other

side. Why don’t they understand the message you're trying to put through? What

can be done differently? A different pitch? Louder? Different colors? Trial and

error are a must on finding a solution. You have to be willing to fail first in order

to get to a better situation later. Failing is part of the process. And the best way

to keep seeking a working solution is…

http://en.wikipedia.org/wiki/Monty_Python

http://en.wikipedia.org/wiki/Terry_Jones

http://en.wikipedia.org/wiki/John_Cleese

http://1.bp.blogspot.com/_yRrxfYiMBlo/TTCA3_7JRcI/AAAAAAAAAXg/o4MMhIpwLIs/s1600/broken+mug.jpg

http://4.bp.blogspot.com/_yRrxfYiMBlo/TTCCSVoYpVI/AAAAAAAAAXk/pJ-HZUBt1gc/s1600/solution.gif


Step 3: Two way feedback

Give and ask for feedback. This was the turning point on this sketch. Time after

time we forget this. Remember the last time someone sent you an email asking

you to do something and you replied saying “So what you want me to do is this

and that?” Right, if you’re like me that was a long while ago… Give feedback even

if no one asked for it. Things can only get better if you do.

Back to the sketch that's how they worked it out: a higher register now, and the

gentleman would try a higher register.

Step 4: Problems can get worse

And they do many times...

And so the problem was solved using the first 3 steps alone. So why the 4th? If

you remember what happens when the other policeman (played by Graham

Chapman) enters to replace the first one - the problems start all over again. And

again, as soon as they get the communication flowing things get worse again

when the inspector (played by Eric Idle) enters the scene. But in the end you have

communication flowing – the Monty Python way.

So don’t forget to keep the communication flowing and watch for more

problems…

Impacts on Project Management

You might have heard that over 90% of a project manager’s time is spent

communicating. So there you have the impact. And if you think a bit about your

communicator role as a project manager there’s so much you can do to make it

better. The real problem here is that in general we don’t accept the fact that

there is a communication problem. We tend to think that the problem, when we

detect it, lies with the others. “I clearly said the meeting was at my office, it’s not

my fault he didn’t know we moved”. Like I said earlier, when was the last time

you took the initiative to give feedback to clarify an email?

To conclude

http://en.wikipedia.org/wiki/Graham_Chapman

http://en.wikipedia.org/wiki/Graham_Chapman

http://en.wikipedia.org/wiki/Eric_Idle


http://1.bp.blogspot.com/_yRrxfYiMBlo/TTCESjjgc1I/AAAAAAAAAXo/V2VI5swMdRM/s1600/mess.jpg

http://3.bp.blogspot.com/_yRrxfYiMBlo/TTCFSCd21CI/AAAAAAAAAXs/hIn_GRdc7ws/s1600/impact.jpg

http://4.bp.blogspot.com/_yRrxfYiMBlo/TTCGPN0Cz_I/AAAAAAAAAXw/cPDwFp07Bkc/s1600/communication.jpg


This "4 step solution" to every single communication problem in the world is, of

course, nonsense. But it worked for the Monty Python so why won’t it work for

you?

Step 1 is the real issue here, I think. Sometimes you have to be brainwashed first

if you want to accept the fact that you have a problem. This is, I believe, because

it messes with people’s habits. And although it’s not the same kind of habit, it has

some similarities to drugs and alcohol dependency and why it’s so hard for

someone to break free.

Others can spot our communication problems a mile away but it’s really hard for

us to do it for ourselves. Have you ever taught a class? Were you ever recorded

on video doing that? If you have you know what I mean, it’s way too weird to see

yourself doing and saying things that you could swear never happened. Maybe

you should trust more what others hint you. Maybe when someone tells you

something like “Why were you picking on Mr. X?” what they are trying to tell you

is “You were way out of line with Mr. X, if you have punched him in the nose it

wouldn’t have made any difference”

Just keep in mind that you should look out for communication problems and

address them at once. It won’t be easy but if you do it…

…then you could be a better project manager.

Images from http://juniorlawyersunion.blogspot.com,

http://www.mathwarehouse.com/, http://www.vibrant.com/,

http://jmorganmarketing.com, http://msu.edu



What is a successful project? - Guest post on pmosig

"What is a successful project?" has just been posted on pmosig.

"A project that delivered on time, on budget and in scope for the planned quality

is usually considered a successful project. But this isn’t always so."

Continue reading on pmosig...

Image from Bruce Berrien.

http://www.pmosig.co.uk/2011/01/17/guest-blogger-what-is-a-successful-project/

http://www.pmosig.co.uk/

http://www.pmosig.co.uk/2011/01/17/guest-blogger-what-is-a-successful-project/

http://www.flickr.com/photos/bruceberrien/391713643/

http://4.bp.blogspot.com/_yRrxfYiMBlo/TTR8_awLciI/AAAAAAAAAX4/8K0mTIgWOKk/s1600/success.jpg


Our iceberg is melting by John Kotter and Holger

Rathgeber

Link to Amazon.Com

This book is about Change Management, not Project Management. But both are

related, in fact my very first post on Ah-Ha-Moments was about Change

Management.

This book is listed here for 3 reasons:

1. It's a book about something that impacts Project Management 2. It explains in a very simple way (using penguins) a process to deal with

Change Management 3. It's fun!

Did you ever learn about John Kotter's Eight Step Process for Change

Management? This book explains Kotter's process using a fable. It tells the story

of a penguin colony that is faced with a challenge that requires a profound

change in the entire colony. The characters in this story are penguins and they

map the attitudes usually found in people when facing such challenges. You will

recognize immediately some of them, like the penguin No-No - even his name

maps his attitude.

This book is relevant for project management because it's about change

management - and all projects make some kind of change. I have talked about it

before on this post. And it's in the form of a fable which makes it a good book

even to kids - no kidding.

The process described consists in 8 steps:

this picture is a link to Amazon.Co.Uk

1. Create Urgency 2. Form a Powerful Coalition 3. Create a Vision for Change 4. Communicate the Vision 5. Remove Obstacles 6. Create Short-term Wins 7. Build on the Change 8. Anchor the Changes in Corporate Culture

http://www.ah-ha-moments.net/2010/05/project-management-and-change.html

http://en.wikipedia.org/wiki/John_Kotter


http://www.amazon.com/gp/product/031236198X?ie=UTF8&tag=ahhamome00-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=031236198X


The book starts with a penguin named Fred discovering that the iceberg where

his colony lives has a crack and is melting. A cracked iceberg could disappear in an

instant, which would be devastating to the colony. From this point on, the colony

goes through the process described above and the book describes it with some

detail. It doesn’t take great effort to map these hypothetical situations to what

you might face in real life scenarios. Including how they deal with No-No: they

get a team of penguins whose job is to keep No-No too busy to interfere with

their plans. I never had to put this in practice, but it sounds effective.

But I don’t intend to tell you the story here, spoiling all the fun.

What I do want to tell you is that this book should be read by any Project

Manager.


AHA! Skipping Change Management is Poor Customer

Service by Margaret Meloni

As a new project manager it was glaringly obvious to me that my success was

largely dependent upon customer satisfaction. I knew that I needed strong

collaborative relationships with my customers. I needed them to respect me and

trust me to get the job done. I needed them to help keep the project priority high

and to provide financial support and subject matter expertise.

I loved giving them good news and I hated giving them bad news. For some

reason I came up with this equation:

Announcing new requirements (or any change in direction) as a scope change =

bad news

Now maybe this was because whenever I suggested to my customer that his new

request was in fact a new request; he said things like “No, this is what I always

wanted.” Or “I thought this was already in scope.” Not wanting to provide poor

customer service I would go back to the team and have them incorporate the

changes.

And this is when I learned that my wonderful customer with whom I had amazing

rapport and respect had no clue why the project was late or why it cost more

money. Let me be more accurate about this point. My customer was able to

pretend he did not know why we took longer to complete the project because

there was no proof that we incorporated any changes. Why should he sit in a

meeting and admit that he added time to the project by adding additional

requests? He was not a bad guy; he was just being politically savvy. Why, it was

as-if all of those conversations and agreements about adding five more days to

development for more in-depth error messages had never occurred. How could

this be?

Sure my customer was happy; the end result was exactly what he intended all

along.

No changes occurred; everything was in-scope from day one. This was simply

another case of Information Technology taking too long.

And I had learned a new equation:

Skipping change management = Undocumented overages plus poor customer

perception

I moved on, determined to be a better project manager and to continue to enjoy

a great working relationship with my customer.

http://1.bp.blogspot.com/_yRrxfYiMBlo/TRGtfF9uvPI/AAAAAAAAAVY/uBQQFs4C_TI/s1600/MMeloni-ProHeadshot-244x300.jpg


You can bet that on my next project there was change management. I

documented it in the project plan and I reviewed it with the entire team. And

when the first change surfaced my customer refused to fill out a change request.

I explained that without the documentation there would be no change. I decided

to be helpful by completing the change request for him. All he had to do was sign

it.

As you may have guessed, this did not make it easy. Now the perception was this

was a form that had to be filled out by Information Technology for Information

Technology in order to keep the project moving. I was still missing customer buy-

in. And so I learned:

Change management without customer participation = Documented overages

plus poor customer perception

I did not give up on change management; instead I learned that I needed my

customer to be my partner in the change management process. They needed to

understand and support the process. They needed to see the value of tracking

changes and I needed to understand that expecting their support and

participation was good customer service.

Well when the second project ended I was able to show which part of our

schedule and budget variances were due to project changes. My customer could

not dispute this; he had signed the change requests. Guess what happened in our

next project together? My customer was onboard with change management. He

worked with his team to do a more complete job of defining the scope and he

worked to discourage unnecessary changes and he reviewed and discussed the

changes that made sense.

As you can see I had a few ‘Aha’ moments as I found my way as a new project

manager. I think these four points capture the essence of my ‘Aha experience’:

Best practices exist for a reason, to help us not to hinder us. If you choose to disregard a best practice like I initially did by not having a scope change management process and you have a bad experience, you really need to revisit that best practice. If you disregard the best practice again and you still have a bad experience, shame on you!

You teach people how to treat you. At first I taught my customer that all he had to do was hint that he was upset about a change being treated like a change and I would back down and incorporate that change without any documentation.

People will do what is easiest for them. In hindsight I truly believe that my customer knew that a scope management process was the right thing to do, but it was easier for him to have no process. If I was not going to follow recommended project management practices and that worked for him, he was not going to say a word.

Skipping scope change management was actually poor customer service. It prevented me from providing my customer with an accurate accounting of what we really provided him for the time and money invested in the project.

Margaret Meloni supports project managers as they navigate the exciting yet

sometimes challenging situations they face on their way to meeting all of those

critical milestones. She does this through teaching, coaching and writing. Her goal

is simple, to help you "end your day at peace and not in pieces." Visit Margaret at

http://www.MargaretMeloni.com

http://www.margaretmeloni.com/


Is focus what you really need?

Sometimes awareness and a broad vision can make a difference

Here’s a simple test for you: just count how many times the players on white shirt

pass the ball. It will only take a minute or so and you’ll learn something about

yourself. Don't skip it please, I'm trying to make a point here!

Done it? Chocked? Did you replay the video to make sure what you missed? I

did...

Focus is a good thing

When you focus you can do more things, you’re more productive. And this is all

true. Being productive and efficient is what projects are all about: you need to do

things right and do them fast and cheap. When you focus you ignore what

happens around you and so you're not distracted. You don't interrupt what

you're doing and you're able to get your flow of work going. And so you definitely

want focused people working on your project team.

The thing is: projects are unique. And they tend to change over time.

When you plan a project there is no way you’ll ever plan it 100% right in the

sense that everything will go according to your plan: you'll get people that fight

each other, you’ll miss an assumption, some business link will somehow pop up

in the middle of the project or some risk will impact the project much harder

than expected. The fact is that you initial plan is bound to change a bit as the

project goes. Add the fact that things change over time (new and more attractive

business opportunities require channeling more resources to it, the economy

falls, your company merges with another one or whatever) and there’s a serious

impact on your project. There is no one in the world that can do something for

the first time always right, time and time again. These are all unpredictable

things that we don't know what they are (most of the times a mistake, a change

or unexpected human interaction). In fact, we don't know that we don't know

and that's why they're called unknown unknowns.

http://1.bp.blogspot.com/_yRrxfYiMBlo/TUKuYtPg4QI/AAAAAAAAAYY/0GmSsBqxnME/s1600/magnifying-glass.jpg

http://1.bp.blogspot.com/_yRrxfYiMBlo/TUKzBLlXjmI/AAAAAAAAAYc/ia-kJNo2_Ns/s1600/Sfinge.JPG


Of course you could try to get someone on your team that is able to foresee the

future but I think the really good ones are really short on supply. Still, you know

something unexpected will happen. But what happens to your project and the

resources it needs if you don’t somehow account for any of this? The resources

can be wasted. That is, knowing that a merge is about to take place could

eventually help you change and adapt your project so it would integrate the

business needs of the other company or whatever makes sense in your particular

case. It doesn't solve the problem, but it gives you more time to think about how

to turn things right.

Does focusing help?

All this talk may seem out of place when the intent is to talk about focus. But

consider this: what does focus help you as a project manager on dealing with

these unknown unknowns? My first guess is absolutely nothing. On the other

hand, does it prevent you dealing better with it? I’d say absolutely. If you are

focused on the project with your team 100% of your time I’d bet you’ll be the

last one to know when such a change (like a merger) happens and impacts your

project.

Focus and the window of opportunity

The sooner you know about these changes the sooner you can incorporate them

in your project and the wider your window of opportunity is. Compare that to

being presented with the facts: hey, we merged with a company yesterday, your

project doesn’t make sense anymore for they have a working product developed

already and so your project has been canceled, sorry about that. Huge difference,

agree?

Focus is great but...

Focus is great and you can’t manage projects successfully without it. But a

broader vision and a sense of awareness can prevent you from sinking. You can

buy a dog (I've been told that's a great help) and you can even do it by having

lunch once in a while with people around the project that don’t actually work on

the project. Having lunch with the sponsor once a week is a great thing you

should probably already do. Why don’t you take that time to talk to him or her

about what’s going on on the organization and not restrict the conversation to

project related items? Think about it: it’s free! And it could place you in a very

favorable position regarding your project!

Conclusion

Use some time to talk about your business environment with your colleagues and

stakeholders. Don't forget your sponsor. And don't discuss your project only. If

you do this the chance you notice there is a gorilla passing by is much stronger.


http://1.bp.blogspot.com/_yRrxfYiMBlo/TUK1yyK8l0I/AAAAAAAAAYg/kYvhKunKXkk/s1600/cartomancy.jpg

http://2.bp.blogspot.com/_yRrxfYiMBlo/TULoS4l3ZAI/AAAAAAAAAYk/9NiQIREoH1M/s1600/Piazza_Navona_360_panoramic_view_9881px.jpg


And once you start seeing the gorillas...

Then you can be a better project manager.

Images from http://splitscreen-blog.blogspot.com,

http://commons.wikimedia.org, http://www.elmwoodmagic.com


Aha Moment: Technical People need Project Managers

by John Bauer

...even if they don’t want to admit it

Like it or not, technical people need project managers. Yet, ask the average

software developer, systems integration engineer or infrastructure engineer

about what their company needs more of role-wise and they will almost without

a doubt say: “We need more X’s. I’m buried in work!” Feel free to replace “X”

with whatever job title applies to whom you are questioning. Software

developers indicate they need more developers because the product owners

keep asking for more features faster than can be developed. Infrastructure

engineers say they need more engineers on their team because they can’t keep

up with the growing demand for more storage, more servers to host systems, etc.

What you rarely hear is a technical person saying:

“What we really need is a stronger project manager who can work with the

project sponsors to prioritize their requests for work so I can focus on the most

important requests first as well as a project manager that can remove barriers

and align peer resources more effectively and efficient to aid in completing that

prioritized work.”

Yet, in an alarming number of instances, this is really what they need. If another

technical person was added as a peer, sure, some additional work would get

accomplished. Without the prioritization and structured sequencing a strong

project manager could bring, my argument is the total output of 2 technical

people is less than 1 technical person pared with a strong project manager in a

medium to large organization. (I don’t have true small/startup company

experience, thus I can’t honestly comment on how much output a project

manager adds when the company itself is made up of only a few people.)

If you hang around with technical people, they tend to place perceived value of

fellow employees based on their interpretation of those employees’ technical

competency compared to their own. Software developers tend to rank others

based on elegant code output and depth of demonstrated coding experience.

Infrastructure engineers tend to rank others based on proven mastery of multiple

vendor hardware and operating system platforms as well as the scope of

technical career experiences and environments.

My aha moment in appreciating project management was when I experienced

the incredible level of increased team output when a highly functioning technical

team is paired with a strong project manager. A surprising outcome was the level

of mutual respect that grew between these two almost divergent disciplines.

Engineers previously commented: “What does that project manager do everyday

besides sit in meetings and tell me to do stuff?” Now, teamed with a strong

project manager focused on ensuring their project work was prioritized and

sequenced based on their feedback, respect for project management grew. The

project manager didn’t just look at the technical team as resources on his or her

http://4.bp.blogspot.com/_yRrxfYiMBlo/TT9QquZriuI/AAAAAAAAAYQ/vZA-w296dhA/s1600/John+Bauer.jpg


Gantt chart. The project manager saw value in having a stronger project plan and

a higher degree of confidence on the dates by spending time with the technical

team members to get into their heads and understand what is really takes for

them to complete project deliverables.

The results of this effective teaming: true cross-discipline collaboration was

witnessed and the results were impressive in both speedy quantity and high

quality.

John Bauer (@jfbauer) is an experienced project solution delivery leader working

in medium to large size companies that consume rather than produce

technology, adjunct professor and is the author of “Midwest IT Survival.com” a

blog focused on the lessons learned in leading technical teams focused on project

delivery in such non-IT industries.

http://twitter.com/jfbauer

http://midwestitsurvival.com/


The Art of Funding and Implementing Ideas

Link to Amazon.Com

by Arnold R. Shore and John M. Carfora

This is a book with great value for those Project Managers that are involved in

submitting proposals. It’s not a book about Project Management but it offers

insight on what goes on in the minds of sponsors when they’re deciding if a

proposal is to go through or not. Actually the authors don’t call them sponsors as

they use a non Project Management language but the role is the same - people

who have the resources and the interest in turning good ideas into real outcomes

that bring some kind of benefit to a particular community.

The authors offer a good description of the proposal process in this book:

(...)The endpoint is a successful proposal. The starting point is an idea. The point

of connection between initiative and idea is the proposal.(...)

This book is written for academics (namely researches, doctoral and postdoctoral

students) looking for funding by Universities and alike. What goes on for them

then is not much different from the case of ideas looking for funding in your own

organization. The language used is also different but the parallelism is quite

obvious and it doesn’t stop you from getting this book’s value out. So although

it’s intended for academics, Project Managers and other Project Management

professionals can make use of this book, specially if they participate in the

proposal process.

The book offers a hands-on approach thanks to their authors’ field experience. It

gives a method you can follow in order to present a proposal that the sponsor

can easily value and discuss with you. This is a key point because many times we

see a proposal that makes every sense even for the sponsor but the sponsor may

not have enough resources for it. If the proposal is built like a rigid block, that is,

either all goes or nothing does, the proposal gets rejected when what everybody

really wanted was to get it approved - even the sponsor. And all this just because

the way the proposal was built gives no margin to negotiation.

http://www.amazon.com/gp/product/1412980429?ie=UTF8&tag=ahhamome00-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1412980429


Link to Amazon.co.uk

One other interesting point made is the difference between outputs and

outcomes. In this book, outputs are what you get out of the project (like the

project’s deliverables). Outcomes are what the sponsor wants to accomplish. For

example, an outcome can be presenting quarterly results on the 6th working day

of the following quarter. Outputs in these case could include a software upgrade.

So the outputs of your project is what makes the outcomes become real. As a

Project Manager you should have the outcomes present all the time and make

sure that your project’s outputs will help achieve them. In other words, if you

have an output that isn’t needed by any of the outcomes you should probably

discard it. In this example, you should remember at all times that the software

upgrade you’re delivering serves the main purpose of anticipating the

presentation of quarterly results.

The method the authors describe requires you to go from idea to proposal and

then back again. Imagining a certain result and then go back to check what you

need to do in order to get there is something natural for us: “(...)Harold Garfunkel

(1991) argues that people plan from the present back to the past.(...)”. This

actually makes sense to me and not because of techniques such as visualization. I

don’t know for a fact why this is so, just that it works for me, to start with a

scenario I wish to achieve and then go back and check what is there to be done in

order to get there.

Finally, it’s funny to see that some of the Project Management trends related to

soft skills are in focus on this book. Just to put this into perspective, there aren’t

that many lines dedicated to soft skills on the PMBOK (that's the PMI Project

Management framework). But the authors see people as central to this “going

from ideas to proposals” business. And I agree absolutely: it’s people who are

funding you, it’s people you have in your project working to achieve the

negotiated outcomes and there will be (hopefully) people using your work to

maintain it and further develop it.

In short, this isn’t the first book a Project Manager should read but it can be very

useful. And I’d add you should read it if you’re involved in the making of

proposals.

Book details:

Title: The Art of Funding and Implementing Ideas

Author(s): Arnold R. Shore and John M. Carfora

Publisher: SAGE Publications

ISBN: 978-1-4129-8042-5

I'd like to thank Arras People for sending me this book.

http://www.sagepublications.com/

http://www.arraspeople.co.uk/

http://www.amazon.co.uk/gp/product/1412980429?ie=UTF8&tag=ahhamome-21&linkCode=as2&camp=1634&creative=19450&creativeASIN=1412980429


My Ah-Ha! Moment by Pam Stanton

“Ah-Ha” moments are so wonderful. Here’s a story of one such moment, when I

was struggling to have my project team produce a plan

We were tasked with the objective of deploying a new desktop operating system

(Windows VISTA) to our business unit. Turns out in order to secure funding, we

would first need to develop a proposal for leadership review. That would require

a plan. Furthermore, the enterprise IT shared services organization was

demanding the submission of our deployment schedule within a month. There

were a lot of politics and optics to this situation, so not complying was not an

option.

I gathered the entire team and explained that we needed to deliver a plan.

“Application Leads, when can you have your applications ready to run on the new

operating system? How much will it cost? And Site Leads, how many computers

can we do per day at your location, and when can we start?” Not so easy. They

pushed back, a lot! They didn’t know how many applications we had in total, or

how well appplications would perform under the new operating system. They

didn’t know whether deployment was going to be “automagic” or require a

hands-on approach. It wasn’t clear whether we had a choice of Window versions

or would have to standardize on one. Aaargh. Nothing was accomplished at that

meeting, except a lot of spinning and complaining as people fed off each

another’s perceived barriers.

I thought it might work better to have each team member sketch out their own

plan first, and then we would combine all the plans. I sent them off for two weeks

to work on this individually. When we reconvened, I got a whole lot of nothing.

“Too many variables!” “How can we price something when we don’t know what

it is?” “How can we build a plan before we know what technology we’re using,

what deployment method we’re using, etc.?” “Sorry, but we can’t build a plan

until we have all these questions answered first.”

At the same time, I was getting my butt kicked by my boss, who wanted to see

some evidence that I had this thing under control. Furthermore, the deadline for

submitting our plan to the shared service organization was looming. I was

stumped at what was holding us up in building a plan. I mean, let’s just throw

some ideas on the whiteboard and build some possible scenarios. What’s so hard

about that? To me, that word “plan” wasn’t very charged with commitment—

heck, plans are made to be broken, just like rules, right?

Ding ding ding! I heard the bell ringing in my head from my executive coaching on

social styles at work. I’m what’s called an “Expressive” (no big shock there, eh?)

Expressives paint pictures with words, in broad strokes. And here I was with a

team full of “Analyticals”, technical people who make fact-based decisions and

commit to plans that are grounded in data. I was asking them to violate their core

Analytical principles by demanding a plan in the absence of facts. To them, a plan

meant that they were accepting accountability for deadlines and deliverables.

“Plan” was a bad, four-letter word!

That Ah-Ha! moment of insight that made a huge difference. I immediately

http://3.bp.blogspot.com/_yRrxfYiMBlo/TUW00ZrVPKI/AAAAAAAAAYo/8pHgpNYvEwc/s1600/Pam+Stanton.png


stopped using the word “plan”.

It was crunch time. We gathered the entire group for an all-day jam session. I had

already drawn a large timeline on the whiteboard and written the words “What

If…?” When we changed the exercise from developing a “plan” to building a

“what-if” scenario, the floodgates broke wide open and the ideas poured out. Of

course, the “What If’s” were all assumptions that would need to be met in order

for those dates and deliverables to work. Fantastic! That’s all I ever wanted to

know.

By the end of that day, we had a picture of how this project could work, assuming

that we could get certain commitments on resources, technology, funding, etc. It

wasn’t a huge Gantt chart, but rather a simple one-page graphic with large

colored boxes and stars that showed major milestones. Now I had something to

show leadership and start negotiating for what we would need in order to

commit to this as a plan. I’ve come to call this approach an “Assumption-Based

Scenario” and find it works extremely well, especially with very analytical teams.

Ah-Ha! This experience reinforces my core belief that methodology gives us a

wonderful bag full of tools, but it is our emotional intelligence that enables us to

choose the right tool for the right situation. Methodology alone won’t get us

there, and as project managers we must continue to build our soft skills and

emotional intelligence in order to know what tools to apply at any given moment.

Pam Stanton

The Project Whisperer

http://www.pamstanton.com

Pam Stanton is a fresh and rising voice in the world of project management. She

teaches companies and individuals to recognize the human dynamics that impact

project success. Her book “The Project Whisperer” shares two decades of insight

and experience on the importance of the Human Part of the Gantt Chart.

http://www.pamstanton.com/


ScrumBut is a good think after all

And a lot of work

A joke to start

Did you know every German factory has a Portuguese guy working there? He is

locked inside a glass dome with a sign that reads: In case of emergency break

glass.

I’ll explain this joke for you just in case you don't know anyone from Portugal.

Portuguese people are very nice and kind. We truly enjoy making other people

comfortable and we are also very adaptable and full of initiative, which is a good

thing for work in general. But... We can break any rule of any kind that anyone

can think of. Thus the joke. When you have your processes running smoothly (a

stereotype for the German way) and everyone is happy (ok, not a great match

for the German stereotype) with the results they’re getting, I can assure you that

the last thing you want around is a Portuguese guy. But when things get off track,

and you need someone who’s not afraid to try out new things, then a Portuguese

guy is a great option. Note: (i) I have to thank this joke to a good German friend

of mine and (ii) the use of "guy" is meant to replace either man or woman and is

not gender specific.

Agile in a glass dome

And this is why I like Agile. Agile is the poor guy locked inside the glass dome.

He’s the one willing to fail while trying to make things work. But on the other

side, you probably don’t want to be all that Agile when you have everything

running smoothly, just like the German factory doesn’t want the Portuguese guy

to be in the way. Let me elaborate a bit on this.

Where Agile fits in

Think of a marketing project. It’s very common to have marketing projects

starting with a deadline, a budget and some needed outcome. And no clue as to

what to do. It’s not too farfetched starting to think about getting email addresses

for some Newsletter with a particular target audience and end up with a new

http://3.bp.blogspot.com/-WLBnm45ia_0/TVPd-0JiQvI/AAAAAAAAAZI/jj_QAK0VRJI/s1600/www.mysafetysign.com-Break-Glass-Emergency-Sign.gif

http://3.bp.blogspot.com/-b-xHP5fUTYY/TVWZ5bshvSI/AAAAAAAAAZQ/PZOuBbcuxwg/s1600/glassdome.jpg


stationary. Agile is perfect to get a grip on this. A couple of examples of Agile

approaches for this particular case may clear things a bit:

1. Having short term deliverables (or sprints) helps you correct course faster;

2. Having a demo helps everyone involved realize if what is being done helps to achieve the desired outcomes.

Both these examples contribute to solve problems that this type of project brings

because:

1. You'll probably change it frequently and drastically as you don't have a way to know what your project is supposed to do, you just have a needed outcome;

2. You have to make sure you're working for the desired outcome and not doing things for the sake of doing them.

Where Agile doesn’t fit in

Now imagine yourself managing a construction project. These projects are bound

to change as well, but they change in a different way. If they had the same kind of

radical changes that are common in marketing projects, you could start a

construction project for an Hotel and end up with a bridge. I’d say this kind of

change is near impossible for this industry. And I'd say Agile doesn’t feel fit for

these projects.

And we get to the ScrumBut

In the middle of this type of projects lie most projects with a wide range of

characteristics associated to. Each of them has its own problems and for each of

them you have to find a solution.

For instance, in a software development project where there is no trust between

the customer and the project team, Scrum as it is won’t work. But. Consider this:

why not get someone with a Business Analysis background into your Scrum team

and turn him into the Product Owner? Would that work?

This is a choking thought. Next thing you know you’ll have a Design sprint... But

then again, who cares? As long as it makes your project work out and you a

better Project Manager...

And in this scenario, adding a Business Analyst to your project could be the

solution. For starters you wouldn't have a trust issue. And someone with a

Business Analysis background would probably have the required sensibility,

knowledge and expertise required for the Product Owner role.

So getting a framework (Scrum or whatever) that solves most of your problems

and changing the things you need to solve your particular problems in your

particular project is in fact not only a good thing to do but the best to thing to

do. Of course this is not all that simple as you have to make sure that the

resulting “framework” works. Two year sprints doesn't sound very manageable

with Scrum, does it? It’s much easier to go for Scrum and then if things go sour

you can always blame it on Scrum itself.

But where’s the data?

http://3.bp.blogspot.com/-mE7u0vZXOAA/TVWa94-YeaI/AAAAAAAAAZU/J8dJGRb5vsg/s1600/construction.jpg


I feel I have to add a final comment as I don’t have any hard data to back up all

this. But at least you have to agree that this makes sense: there is no one recipe

to solve each and every problem that you can find in a project, on any kind of

project. You can find this same approach on some literature. One book that

comes to my mind is “Agile Adoption Patterns” by Amr Elssamadisy. I’ve read it

some years ago and I really enjoyed it. I’m actually planning on reading it again in

order to review it here, but in general the book goes like this: you have a

particular problem in your project and Agile has a solution for it; and then the

author explains how the proposed solution helps solving the problem and the

pros and cons of using that particular solution. This makes all the sense to me.

But it forces you to adapt to context. And to think about solutions. And to check

if they actually did work. And all this means a lot of work.

On the other hand, it’s much easier to follow some recipe. But assuming there is

one right way to manage all projects can only lead you into trouble. If you put it

this way I guess it’s pretty obvious which way you should go: ScrumBut is the

way. So ScrumBut a lot and maybe then...

...you can be a better Project Manager.

Images from www.mysafetysign.com, http://www.glass-dome.net,

http://technology.amis.nl/ and Joana Ricardo

http://1.bp.blogspot.com/-Wlc6wi3IYNI/TVWbbVu27HI/AAAAAAAAAZY/XBN8ZotrSAE/s1600/data.jpg


Michiko Diby's Ah Ha Moment

A few years ago, I lead a team of 10 business analysts and engineers, testers, and

trainers.

When I first took on the job, the team was organized in a hub-and-spoke

configuration; the lead (my position) was the hub and they were the spokes. And

there were team dynamic problems. People weren’t talking to each other, cliques

had developed and information wasn’t being shared. Funny thing was that most

of the team was in the same large room! They were co-located and I spent the

first month hearing from people who were so miserable at the atmosphere in

that room, that they threatened to quit. I mean... tears... and frustration.

I tried to work one-on-one with each person but found that backfired. What

would happen is that I would have a talk with someone to get to some solutions.

They would go back to the room in a better mood. The other team members

would think that person got something new that they didn’t have. And the gossip

would start again and make things worse.

Meanwhile, the client’s deadlines were fast approaching, the quality of our work

was ok, not great. And after about a month, I started to become the momma on

the team, not in a good way, but in a “I’m going to tell on you to momma” kind of

way. It was nuts. Some people quit.

Around that time I was reading a blog about Google, and how Google allows their

folks to have one day a week to work on an independent project and I thought...

A-HA... That’s it. At Google, employees are trusted to do great work and to

manage their time. The company realizes that smart people do better when they

can be the masters of their own destinies and therefore builds in the time for

that during the week.

Now, giving these folks a whole day to work on their own project was not feasible

given contractual restrictions. But the idea to trust them as smart people who

needed time to stretch their minds and think about better ways to do things, was

something I could work in.

So instead of a full day, I set up working groups that would meet for one hour on

Fridays. The groups were built around software disciplines; systems engineering,

business architecture, testing, training, and QA and change management. When I

introduced the groups, I emphasized freedom. They were free to attend or not

attend. They were free to go to any group meeting. They were free to discuss

what they wanted to as long as it pertained to the discipline, even if that meant

they weren’t necessarily discussing client deliverables. They were free to ask me

not to attend, if they didn’t want the “boss lady” there.

Each group had a leader, but that leader did not have my authority to give work

to others. I still created the project plans and maintained the resource allocation.

http://4.bp.blogspot.com/-CXq6z68G-os/TVa2m8itnDI/AAAAAAAAAZc/2h9f47rmhnQ/s1600/Michiko+Diby.jpg


Rather, that group leader had the authority to be the most knowledgeable about

the discipline and to teach and train others about the discipline. My only real rule

was that I wanted to see the learning applied to our deliverables as soon as

possible.

It felt good. And it took off. The groups started meeting, and elected a leader.

They started talking about ideas and innovation, instead of each other's

shortcomings. Without me in the room, they started to develop new ways of

relating to each other. Surprise, friendships started to blossom.

And our productivity....toook offf!!! We were able to take our organization from a

CMMI 1 to a CMMI 2 in one year. Our deliverables were top notch. We had full

traceability from requirements to development. Our change management

process was well documented, customer approved and tight. We got more work.

The team started doing happy hours together.

My a-ha moment was that people need the freedom to innovate. People need to

be the masters of their domain, they need to be trusted to do great work, and

they should be allowed time to develop their craft. It may feel difficult to ‘let go’

of some authority, but in the end, trusting people to be great yields incredible

rewards. Just look at Google!

Bio: Michiko Diby, PMP, is the owner and principal consultant of SeaLight, LLC.

For more than a decade, she’s been a Change Agent, Project Manager, Process

Improver for Fortune 100, DoD and small and medium sized enterprises for years.

Her popular Project Management blog, Preventing Project Failure, has been

voted one of the top 100 PM blogs by her peers. She is also a leader in the PMI

Washington, DC chapter, chairing the International Project Management Day

committee, and founding PMIWDC Project Manager of the Year award. Michiko

has a Master’s Degree in Conflict Analysis and Resolution from George Mason

University.


Project in your Pocket, by Gareth John Turner

John Turner wrote "Project in your Pocket" for the Project Managers that just got

into Project Management. Even after you get some training on the Project

Management Book of Knowledge (PMBOK) or other similar framework, you still

find sharp edges on the concepts that don't fit together nicely. This leaves you

with the feeling that you're missing some piece of the puzzle. That's the audience

this book was written for, and this is the gap this book was designed to fill.

"Project in your Pocket" is a very simple book. And simple here, like in most

cases, isn't the easiest thing to achieve. "You do not really understand something

unless you can explain it to your grandmother" captures the spirit of this,

meaning that only when you understand something you can get to the essence of

things and expose them to others as something simple. And this book basically

explains how to use a particular template - dead simple. And manage projects

with it. I too have such a template I use in my projects as I suspect every Project

Manager does. The thing is that this particular template focus on just the

essential that goes on on a project and really lets you focus on the core stuff and

put all else aside to address when needed. It's not that the other stuff isn't

necessary; it's just that you have to get the core in place first. Plus, on explaining

how to use the template, John Turner gives a time line perspective that works for

filling that gap that new Project Managers feel.It's so true that the focus of this

book is the core of Project Management that it doesn't really matter what

framework you use, you'll always have that core. You can do Software

Development with an Agile approach and use this template, you can work on a

consulting company with a Project Management Office in place following the

PMBOK and use this template and you can do construction projects on a small

company that just builds stuff with no Project Management process in place and

still use this template. This is some extraordinary achievement!

"Project in your Pocket" is written with an attitude I appreciate very much. He

puts practice above theory. One example is building Work Breakdown Structure

(WBS) using Mind Maps. Actually he puts an example where there's a work

package composed by just one other work package - that's a no no. There are 2

dangers with this: (i) people that don't know what a WBS is are going to learn it

wrong and (ii) it doesn't work for projects with some complexity. But you know

what? It works!

The last thing I want to say about this book is that it follows an example from

start to end. The example is great, the project in focus is putting together the

members of an old band for a one time concert. The book walks you through the

10 steps of the template and in the end of you have the template completed with

this project's information all in place. From start to end, John Turner shows how

to use the template, what to do first, what goes next and what to do last.

To sum it it up: "Project in your pocket" is a must read for anyone starting on

Project Management and a useful and insightful tool for Project Management

professionals in general.

Note: "Project in your pocket" will be available on Amazon in approximately 6

weeks. I'll update this post with the respective links when that happens.

http://www.projectinyourpocket.com/

http://www.projectinyourpocket.com/


Beginners Guide to Project Management

Part 01 What is Project Management

Introduction to this guide

Audience

This guide was built for 2 different audiences. If you’re starting on Project

Management this is a perfect place to start because it links the main concepts in

a time frame perspective that makes learning about Project Management much

easier. And for the same reason, it also serves perfectly well as a reference book:

it links the main Project Management concepts.

Objective

This guide is still under construction and it will be published during the next few

months on the Ah-Ha-Moments blog (http://www.ah-ha-moments.net). When

completed, it will be available there as an eBook for you to download. The main

objective is to offer a guide to Project Management that you can use and follow

as the project evolves, giving you a sense of a time line that usually is missing

from the literature.

Content

This guide contains all the main ideas related to Project Management and it will

be supported extensively on Project Management Institute’s (PMI) “The Project

Management Book of Knowledge”, 4th Edition (from now on referred as the

PMBOK). Supporting this guide on this commonly accepted standard will provide

you with a solid reference point to further explore the concepts exposed.

Part 01 - What is Project Management?

Defining a project

Project Management start with a project and it’s common to define it in several

different ways. But somehow defining Project Management as “the art and

science of making a mess workout right” doesn’t seem neither right nor

productive for the purpose of this guide. So I’ll build a solid foundation first

before we play around with these concepts. On the PMBOK, a project is defined

as “a temporary endeavor undertaken to create a unique product, service or

result” (PMBOK page 5). A project is always something that joins a group of

people in order to produce some unique result in a defined time frame. In this

definition you have 3 distinct components and these components are always

present in any project you can think of:

A unique result, meaning that if the result you’re planning to get is exactly the same as some other you don’t have a project

Temporary effort, meaning that your project has to finish when the results of your project are done (1 week, 1 year or 10 years are all OK)

Continuous effort, meaning that is not something you will do sometime if you have nothing better to do

http://www.pmi.org/

http://www.pmi.org/

http://www.ah-ha-moments.net/2010/05/project-management-yeah-i-do-that-too.html


http://1.bp.blogspot.com/-LKs0VPEECSI/TWfjxUh8qLI/AAAAAAAAAZ8/_cn00BPpo4k/s1600/wbs.jpg


Here is a list of some projects that anyone can recognize as such:

Building the Great Pyramid of Giza

Putting a man on the Moon

Developing Microsoft Windows

Researching a new medicine

Making a movie

Defining what isn’t a project

Let’s see what happens if we take out one of these components (the unique

result, temporary effort or continuous effort) starting with the unique result.

Suppose you’re having a regular dinner at home with your family. That is not

something unique but it’s time bounded because you’re supposed to have dinner

sometime in the evening and it requires some work as someone has to go

shopping, cook, set the table, do the dishes and so on. Is it a project? Not really,

it’s a repetitive task you do nearly every day.

Do you have kids? Although you make plans for them, like saving money for them

to go to college, you can’t really face them as temporary, can you? So kids are not

a project either.

Do you have a place where you’d really love to go for a vacation? This is

something many people dream of but they don’t work on it every day so I’m

sorry to inform that your dream vacation is not a project.

And here’s a list of things that you can recognize as not being projects:

Crossing the street

Managing assets for a millionaire

Maintaining an oil tanker

Paying your employees

Monitoring your business

Winning the lottery

Oh, there's one other thing a project is not: a project is not a Gantt chart.

What is Project Management

So what is Project Management? Project Management is the management of

projects. This circular definition is good enough to show you that Project

Management is not about doing the project, it’s about making sure people can do

the project, that there are no obstacles in their way, that they know what they’re

supposed to do and that they do it.

In a more pragmatic form, “Project Management is the application of

knowledge, skills, tools and techniques to project activities to meet the project

requirements” (PMBOK page 6). Same thing. But it does add important

information: there is some knowledge, skills, tools and techniques for you to

learn and acquire. This is why Project Management is such a fascinating subject:

You can know it all - but that still won’t make you a good Project Manager

It’s multi-disciplinary, meaning you have to know a bit about: finance, negotiation, communication, leadership, quality and so on

Finally, Project Management is cross-industry (at least as much as it can). In

theory, you can manage any project in any industry as long as you can manage

projects and know a bit about that industry. In practice, some industries have so

much specificities that sometimes it’s really hard to move from one to another.

For instance, the construction industry has it’s own characteristics that separates

it apart (several thousands old, slow technological changes, only a small part of

the work is intellectual, obligation to build what is planned and naturally phased)


and specific legislation that rules it. Even PMI has PMBOK adapted for

construction.

This particular topic is further developed on the article “Project Management?

Yeah, I do that to”.

Where do projects come from?

This is the single most important thing about projects. Projects exist for a single

very simple reason: someone is willing to spend money and resources on them.

Why? Because they expect to get something back based on the project results.

Examples:

You are contracted to build a bridge (this is your project result). Why? Because the local authorities want to increase mobility of the population.

You are hired to upgrade some software (the project result). Why? Because the software builder is about to end the support for the installed version.

You are hired to do a new TV commercial for a particular product (the result is the commercial). Why? Because the company wants to increase sales by 10%.

These “Whys?” are the most important thing on Project Management because:

It’s the sole reason your project exists

If you don’t work on that direction, satisfying that “Why”, your project can end in time, on budget and in scope and will still be a failure for sure

Once you lose sight of these whys your project is lost. Take the software upgrade

example. I don’t think the project would be the same if you were to upgrade the

same software but for another reason: the new version has some dashboards

that the company wants to share at the board and top management level.

Outcomes and outputs

I recently reviewed the book “The Art of Funding and Implementing Ideas”. This

book isn’t exactly on Project Management but has an interesting perspective on

Project Management. One of the interesting things is the meaning attributed to

“outputs” and “outcomes” and I started using them since then. Outputs are the

results your project is supposed to deliver. Outcomes are what people will get

once they have those outputs.

Using these new meanings for these words, you can state that your project will

produce some outputs (following the previous examples: a bridge, a software

upgrade or a commercial) that will allow some intended outcomes to come true

(increased mobility, continuing support and increased sales respectively).

Outputs and outcomes are interconnected. Although your project won’t produce

any of the outcomes, its outputs will have a strong impact on them. And the

outcomes are the reason you have someone spending money on your project. If

they have no use for your project’s outputs, if they don’t contribute for the

intended outcomes, there is no use for your project.

Hence your first lesson on Project Management: keep the relevant outcomes in

sight of your team all the time and make sure everything you do on your project

is connected to the outcomes. If you have something that is not connected to the

outcomes then your project doesn’t needed it and you can throw it away.



http://www.ah-ha-moments.net/2011/02/art-of-funding-and-implementing-ideas.html


Sam Palani's Ah Ha Moment

When Luis Seabra asked me to talk about my Ah Ha moment related to project

management without realizing he had actually sent me on a journey of

introspection.Yes, I did take time. I revisited so many instances over the past

decade of my study and work.

I personally have not been a big fan of Eureka moments and have always believed

that ideas don't happen in Eurekas, but are actually nurtured over over time

(Steven Johnson talks about this in his TED talk - Where good ideas come from)

But then again there those moments that which can be game changers or path

changers that make you take a different perspective.

My Ah Ha moment relates back to a video Steve Jobs where he is addressing a

bunch of awestruck, lucky Stanford Grads.Though I am not a big fan of the

iOS(yet), the guy inspires me for his innovation, entrepreneurial skills and

resilience. In that classic video Mr Jobs talks about two things - Staying Hungry

and Staying Foolish. The later part kind of resonated with me. After all being

foolish we can shed our preconceived notions and ask questions which a “wise”

person might hold back. Of course this is not, easy but once you are able to ask

questions like a fool you quickly see the benefits. In my own experience I have

been able to eliminate, evaluate and and research just by asking questions like a

“fool”. Remember again a fool can ask questions without worrying about the

consequences.

So there it was my Ah Ha moment - Being Foolish when it mattered, thanks to Mr

Jobs and of course Luis making me discover it once again :)

Sam is a certified project manager from PMI (PMP). He also has an MBA in

Information Technology Management and Post Graduate Certificate in

Leadership from Duke University.He currently works and lives in the heart of the

silicon valley in California.He is also founder and the chief contribute for around

the chaos – the blog. Sam believes, however diverse the source of chaos, the

impacts are quite relative, that is the lack of predictability. Although its not

always possible eliminate unpredictability completely, he aims to leverage the

tools, techniques and principles to get around this chaos and avoid butterfly

effects.

You can find him and his work on Around the Chaos.

http://www.youtube.com/watch?v=0af00UcTO-c

http://www.youtube.com/watch?v=Hd_ptbiPoXM

http://aroundthechaos.com/

http://aroundthechaos.com/


Project Sponsorship, by Randall Englund and Alfonso

Bucero

Amazon.com affiliated link

This book deals with project sponsorship by introducing the "sponsorship

staircase" which is an analogy to the necessary steps that one has to take in order

to have an ideal sponsorship. It is particularly interesting for project managers

focused on the relations between projects and businesses, and I recommend it if

that’s your case. But it is not the first book you should buy if you're interested in

Project Management.

It’s a good value

Randall Englund and Alfonso Bucero were responsible for a seminar on project

sponsorship on last year’s PMI EMEA Congress in Milan. I had the privilege to be

on that seminar and I can tell you it was time well spent. The reason I mention

this is because the seminar was built around this book and so there’s a lot of

practical and useful tools like templates you can take from it. But I’ll get to that in

more detail in a bit.

Structure

First I’d like to tell you in more detail what the book is about. The book is

structure using the “sponsorship staircase” which is:

Sponsor responsibilities

Obtaining a sponsor

Sustaining sponsorship

Client sponsor relationship

Steering committees

Culture evaluation

Execution feedback

Sponsorship development

Sponsorship mentoring

Knowledge management

Starting with sponsor responsibilities

http://www.amazon.com/gp/product/0787981362?ie=UTF8&tag=ahhamome00-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0787981362


Affiliated link toAmazon.co.uk

I don’t want to get in too much detail, but they start the book with sponsor

responsibilities. These responsibilities vary with the type of sponsor you have (a

paying sponsor, the sponsor that needs your project’s results to build upon them,

the internal sponsor, the client sponsor, and so on). Add to that the fact that

most sponsors don’t know what their responsibilities are as sponsors and you

have a problem to solve and a topic for a book and a seminar. And a great topic.

What you’ll get from Project Sponsorship

Some of the good values you'll get from this book are:

The disciplines of credibility, they show you how to promote your credibility

Functions of steering committees, they are very handy to show what a steering committee should be concerned about (and also what they shouldn’t concerned about)

Corporate cultures, a simple 4 category classification of corporate culture so you are aware of the environment where your project is running

Roles in Change Management, so you can easily check your part and everyone else’s on the change process that your project is part of

And some real practical tools are also included:

Environment Access Survey Instrument, is a survey that can give you a useful insight about organizational readiness for your project

Risk Assessment Survey, is a scored survey that can also give you a useful insight about the organization awareness on the risk associated with the change your project is to introduce

Political plan, (yes, you read it right!) to give you a tool to position and direct you on your political status on the organization

The book is also filled with alerts and advices. The way they are introduced makes

them plain to see to you and easy to explain. One example that comes to mind is

when they discuss dashboards to oversee projects. Dashboards make sense when

the organization has reached a certain level and they say it like this: sponsors

don't need a dashboard before they can drive. Simple and straight, right?

So all considered, I'd recommend this book to anyone dealing to businesses and

projects - ranging from project managers and sponsors. It's not the first book you

should read to learn about Project Management but it's a book you have to read

in the case you're dealing to businesses and projects.

http://www.amazon.co.uk/gp/product/0787981362?ie=UTF8&tag=ahhamome-21&linkCode=as2&camp=1634&creative=19450&creativeASIN=0787981362



Part 02 Context for Project Management

Objectives

This part 2 of the Beginners Guide to Project Management sets the scenery for

Project Management. Projects are set in a wider environment: they are done for

a reason and their results last longer than the project itself and so in order to get

projects done you have to know where you stand.

Previously on “Beginners guide to Project Management”

Part 01 – What is Project Management

Defining a project



Where do projects come from


The project life cycle

On the last post we started with some of the basic concepts about Project

Management and we'll continue it on this post. The first thing to do is to broaden

our view on Project Management a bit more and check where do projects fit in.

Projects run in organizations during a certain time; during that time you can

identify the following 4 distinct project phases like shown in the picture above:

Starting the project

Planning the project

Carrying out the work

Closing the project

Now things change their impact as the project develops and runs through these

stages. And it’s a good idea for you to keep in mind a few of these things that

change their impact on the project. Some increase their impact along the project,

like the cost of changes. This means that, when you have a choice, you’d rather

have changes in the project in its beginning than further along the way for a very

simple reason: it's cheaper. Because of this, it’s also a good idea to set some

mechanisms to make changes show up as soon as possible.

Others decrease their impacts along the project. Uncertainty is one of them.

Projects are about getting something unique done, so you will know much more

about that unique result towards the end of the project than in the beginning. As

a direct consequence, the same happens for risks – the more you know about

your project the less risk there is.

http://www.ah-ha-moments.net/2011/02/beginners-guide-to-project-management.html

https://lh6.googleusercontent.com/-01BVfV-TbYs/TXprk6oYfVI/AAAAAAAAAao/sViin_HpYXA/s1600/Project+Life+Cycle.jpg


The Product Life Cycle

But this is not all. Projects fit still in a larger context. Weather the project result

(its main output) is a product or not, there is always a larger picture where the

project is set. In the case where the project result is a product, this larger picture

is the product life cycle. But even so, you can look at it using different

perspectives. Using an engineering perspective, the product life cycle involves:

Conception

Design

Manufacturing

Service

Projects that have a product as its main output are set on the design phase of the

product life cycle but you can (and you usually have) projects in every phase of

the product life cycle - but their main output is not the product in focus.

If you use a Marketing perspective, the product life cycle involves:

Market introduction

Growth

Maturity

Decline

The same is valid in this case: projects that have a product as its main output are

set prior to the market introduction of the product.

Projects, Programs and Portfolios

Projects can stand on their own, like writing a book. But in many cases project are

part of something bigger directly related to them. Projects can be part of a set of

initiatives running towards a common goal. This set of initiatives is called a

Program.

Suppose you want to increase mobility in a city. For this single goal you can set

several projects such as:

Expand the subway network (to residential neighborhoods, the city’s airports, downtown, other transportation hubs, and so on)

Build a bridge for trains to cross the city’s river to connect the city’s subway network to the suburb’s network

Build parking lots next to the subway stations on the suburbs

You could set one or several projects for each item in this list but they wouldn’t

exist independently – they have a common goal and they’re interdependent. And

so they should be managed together on a higher level: the program.

Portfolios include projects and programs. The main difference is that the projects

and programs included in a portfolio don’t have to be interconnected and don’t

have to share a common goal. Prioritization is one of the main purposes of

portfolio management and it consists on getting the projects that return the most

value done first.

The Project Manager

The final piece of this puzzle, the project context, is you - the project manager. At

his organizational level, the Project Manager is the one person responsible and

accountable for the project. In order to manage projects successfully, a Project

Manager has to have:

Some knowledge about the specific area where the project is running (is it an IT project? a Health Care project?)

General management proficiency, including the ability to build a business case that will be featured on future articles

Project Management knowledge, tools and techniques, such as task lag and slack that will also be featured on future articles


Personal skills, where leadership, negotiation and communication are included

Another perspective given by the PMBOK is “addressing the various needs,

concerns, and expectations of the stakeholders as the project is planned and

carried out”. A stakeholder is an organization or a person that may either (i)

influence your project or (ii) be affected by it.

Project success

One of the most important things to have in mind is how to measure your success

as a Project Manager. The reason for this is simple: if you want to be a good

Project Manager you have to have a critical view on what you do. But there's

something that has to come first: how do you know if you're doing a good job?

On and on, you’re a successful Project Manager if your main stakeholders are

happy with your project and its outputs. However, you will usually hear that a

project is a successful one when it’s finished on time, on budget, within the

planned quality and with a satisfied customer. This is also true but varying on the

project context there will be one side of this equation that will outweigh the

others. There are situations in which this gets quite complex to evaluate, you can

find some more information on this on this guest post of mine on PMOSIG:

“What is a successful project?”. As a rule of thumb, I identify project success with

happy stakeholders.

Next steps

Now that we have set some language specifics and explored some of the basic

concepts surrounding Project Manager we can get to the juicy parts: you have a

project to manage; now what?

http://www.blogger.com/%28http:/www.pmosig.co.uk/2011/01/17/guest-blogger-what-is-a-successful-project/


Getting to Yes

This is not just any book about negotiation; it’s a mandatory book on the topic.

And it’s relevant to Project Management since negotiation is a necessary skill for

Project Managers. Project Managers have to negotiate resources with functional

managers, the scope of the project that they can fit in a fixed delivery date,

requirements that are nice to have but not really must haves, contracts with

subcontractors and suppliers, sponsor support and everything else that goes on

in a project.

The process

This book is about principled negotiation and it has its own process to go about it.

In short, the process has 4 steps:

Separate the people from the problem

Focus on interests, not positions

Invent options for mutual gain

Insist on using objective criteria

This is not a natural process, when we think of all the things we negotiate on a

day to day basis. It’s much easier to state our wants and just hope that the others

involved agree to it - and it works for supermarkets, they hope you find the price

on cereals fair and buy them, right? But the fact is that you have a lot to gain to

go with this process (when it's worth the effort) because:

It’s fair

Both sides win

The pot being negotiated is usually increased by the process

Relationships are taken into consideration and separated from the problem

It allows you to grow a reputation as a fair negotiator, someone to trust

Interests and positions

Some things to keep in mind about the process include going after interests

instead of positions. Interests and positions are beautifully exposed on the story

of the sisters and the orange. The telegraphic version goes like this: there were

these sisters who wanted an orange so they split the orange they had in half and

each got an half of the orange. One sister squeezed it, threw away the peal and

drank an orange juice and the other just wanted the orange zest, threw the rest

away, and baked an orange cake. This is the difference between positions (both

sisters wanted an orange) and interests or the root cause for taking that position

(one needed the orange zest and the other the juice).

Usually one interest can raise several positions so it’s very useful to go after

interests so you can solve the problem without compromising what each part

really needs. It’s the separation between wants and needs.

Story telling

This book includes several real and fictional stories as good examples of

negotiation. The Camp David Accords is the first that pops to mind as it was

featured on the previous post: It's all about interests, not positions but here are

others.

Another wonderful story to illustrate this negotiation process is a controlled rent

negotiation. This one is very rich on lessons learned and it perfectly shows how



difficult it is to master some of the requirements to negotiation, like separating

people from the problem – can you separate people from the problem when a

discussion heats up and gets personal?

Tools and techniques

Some tools and techniques are also included. Some examples are:

Generating creative options

A brainstorming guide

Problem solving using the circle chart

One text procedure

These will come in handy occasionally but it’s nice to have a place where to check

exactly how to do things. I don’t think I will forget a brainstorming session where

I was once in. Someone got the role of “idea evaluator” so as ideas popped up he

would decide on the fly if it would get registered or not. You can imagine that this

brainstorming session was not a huge success.

Conclusion

This book is a must read to anyone who has already taken the first steps into

Project Management. After the first avalanche of new stuff one learns about

Project Management, negotiation is one of the topics that must be familiar to the

Project Manager as he will make an intensive use of it, either being aware or not.

This book is simple (there are no rocket science concepts), it’s written by people

with a vast experience on negotiation and it’s relevant to Project Managers.

Because all this, “Getting to yes” is a must read to every Project Manager.



Part 03 Where to start

Part 03: Where to start

Objectives

After checking what Project Management is and where it fits, it’s time to start

working. Or isn’t it? This part 3 of the Beginners Guide to Project Management

covers the project start with the business needs that originate projects.



Defining a project





Part 02 – Context for Project Management


The product life cycle

The Project Manager

Project success

Start focused on the end

In general, and Project Management isn’t particular in this case, it is very useful

to keep in mind what your end state is, what you need to have in order to say

that your job is done. When managing a project, the project ends after you

deliver the required outputs you were hired to deliver, right? That’s the “Closing

the Project” part from the previous article. Now these outputs demand some

work in order to come true - and this is the “Carrying out the work” part. And if

you’re doing some work you should plan it before starting it so you know how

long it will take, how much it will cost, what resources you’ll need and so on - the

“Planning the Project” part. So what do you need to have as a Project Manager

before you start planning your project - "Starting the Project" phase?

The Project Charter

If you go to the literature on Project Management, the Project Charter is the

most common answer. The Project Charter is a document that authorizes the

Project Manager to commit resources to deliver some outputs also described on

this document on a very high level. This makes every sense in most situations as

it’s a good idea to be authorized to work on whatever you’re working.



https://lh6.googleusercontent.com/-o3us5LLKkH4/TYzeaD312mI/AAAAAAAAAa8/Y59oHeXfhkQ/s1600/start.jpg


Suppose you start off doing a project to deliver some management tool for a

warehouse and keep on adding features till you end up with a full Enterprise

Resource Planning software including financial consolidation. This is OK, really, as

long as people don’t expect it to cost the same and to take as long as it was

initially estimated. So the Project Charter is most suited to use when things go

wrong than to help you start doing your job, which is the point of this article.

Wants and needs

So what is it that makes you start a project? This is very clear if you think about

your personal projects: you do them because you need its results! It's as simple

as that, there's no rocket science here. Somehow you measure the benefits

(could be money, fun, recognition, or anything else positive that sounds good to

you) against the costs (could be expenses, invested time, your health lost or

something else negative) and decide it’s a good idea; the same goes for the

organization that asks you to do that project: for some reason, they need its

results.

So my perspective on starting a project is to make sure it makes sense, that it’s

useful for the organization requesting it. And then, by all means, cover your back

as good as you can and get a Project Charter signed off.

Why?

So the organization wants to do a project. But do they really need to do it? If

there’s no need you should discard such projects whenever you can - and point

out that there’s no need for them. To evaluate this need you must start asking

“Why?” a lot and to as much people involved as you can. Usually, when someone

asks you to get some outputs with a project, they don’t talk much about the

outcomes they want (more about outputs and outcomes on the book review of

”The Art of Funding and Implementing Ideas”, but outputs are what your project

must deliver and outcomes are what the organizations wants those outputs for -

for example, an output can be a new product but the outcome is the replacement

of an old product to maintain the company's sales on that particular segment).

And the outcomes are the most important thing at this stage so you can

understand what is expected for your project to accomplish. It’s no use for

anyone if you deliver what you’re hired to deliver but it’s of no use for anyone -

and this happens a lot. Or is it just me?

You should start asking "Why?" to the person that is requesting you to do the

project. And assert his role for the project: is he the one who benefits the most if

the project is done? Is he who’s paying for the project? Was he mandated by

someone else and has no interest whatsoever?

Then do the same to everyone that has a role in your project, besides the

previous ones mentioned: the people who are going to use it, the people who are

going to maintain it (remember the product life cycle from the previous article?),

the business leaders who thought the project was a good idea, the supporting

departments (Financial, Human Resources, and IT for starters) and everyone else

that has a clear interest on the project at this phase: either because they’re going

to benefit or suffer because of it, or because they can influence how the project

runs.

Next steps

I hope you’re convinced with these arguments that asking “Why?” is the best way

to start a project. But I also hope you find it kind of short - because it is. Before

you fill comfortable to plan the work to be done there’s a lot more to know about

the project. You already know why people want these project’s outputs, but...

what are the outputs? This is the next question these articles will answer:

"What?"

http://www.ah-ha-moments.net/2011/02/art-of-funding-and-implementing-ideas.html




Part 04 What to do

Objectives

On this article you’ll find the necessary information on what you need to know

about your project outputs prior to planning, namely what your projects outputs

are.



Defining a project








The Project Manager

Project success

Part 03 - Where to start


The Project Charter

Wants and needs

Why?

Outputs and outcomes, again

So by now you already know why your project is necessary. And you should have

a good idea what are the outcomes that your project is supposed to help achieve.

So the next step is to check what are the outputs you have to deliver. Just don’t

forget that the project outputs or deliverables have the purpose to help the

organization achieve the intended outcomes.

The Project Charter, again

The Project Charter should include a high level description of the work to be

done and hence it should include the outputs or deliverables of the project. The

thing with the Project Charter is that (i) either you built the Project Charter

yourself or (ii) it was given to you as is. In any case, there should be a scope

description in it that you, as a project manager, must understand. After all, you’re

the one who’s going to build it, right?



http://www.ah-ha-moments.net/2011/03/beginners-guide-to-project-management_25.html

http://4.bp.blogspot.com/-_wSvbMr-BIU/TZX6vp651CI/AAAAAAAAAbI/9fbU-n2pmj4/s1600/WBS2.jpg


About scope

Scope has a special meaning for project managers. In practice, it translates into

the “Why?”, “What?” and “How?” and you should use them accordingly to your

audience. If you’re discussing your project with:

- a board, you should probably stick with the “Why?” bit;

- functional managers, you should probably stick with the “What?” bit;

- the project team, you should probably stick with the “How?” bit.

But discussing the scope of the project is a bad idea. What part of the scope are

you talking about? The reasons (why), the outputs (what) or the tasks (how)?

Just a note: The first time I saw this so formalized was on a webinar by Bob

Jewell.

The “What” part

The “Why” part was covered on the previous article and we’ll leave the “How” bit

to planning, which will be in the next articles. But even prior to planning you

should have a good idea about what your project will deliver. And make sure that

what is written in the Project Charter is what is really needed by the

organization. The only way I know to accomplish this is, again like in the “Why”

bit, by talking to people involved in the project. The next paragraphs include the

most important things you should be worried about when discussing the “What”

with the people involved.

Alternative outputs

Are there other ways to help the organization achieve the outcomes it needs? If

you can, try to get 3 different sets of outputs that still enable the organization to

get the required outcomes: the cheapest ones (with a focus on cost), the fastest

(with a focus on time) and the best (with a focus on quality). In most cases, the

outputs you will be contracted to deliver is a combination of outputs from these

different sets. And sometimes, there is only one set of outputs that will satisfy

the required outcome.

Wants and needs

Sometimes wants and needs sound the same, but wants and needs are different

things. Keep this in mind at all times and focus on the needs. If someone

expresses a want in a meeting, explore it and question the person until you get to

the needs behind that want. This is not always easy, but it’s essential to succeed.

You’re not planning

It’s all too easy to see yourself planning the project in these meetings. It’s good to

keep in mind that you are not planning what you will deliver yet. You’re just

checking out if there are alternative ways, if it makes sense, if this project is what

is needed. And you’re not committing yourself. Yet.

Next steps

The next article on this series will be a case study that will serve as a guide. The

objective is to have a fictional project where these suggestions are applied to so

you can have a feeling of how you can apply this guide to real case scenarios.

http://www.pamstanton.com/Blog_new_Pam_Stanton_Project_Whisperer.html



Hunting for Shark's Teeth and Project Management by

Neville Carson

Recently, the family and I spent a week at the beach on beautiful Amelia Island in

northeast Florida. One of the many great things about this beach is the shark’s

teeth you can find. A shark’s tooth, once it falls out of the creature’s mouth to

the ocean floor, spends many years becoming fossilized. Then, thanks to the

action of tides and currents, some of these shiny, black beauties eventually find

their way to shore.

As I wandered the shore looking for shark’s teeth, my mind turned to

management. (I am thinking of getting counseling to stop it from doing this, but

for now, it can’t be helped.)

Does the pursuit of shark’s teeth have anything to teach us about our trade?

Maybe it’s just sunstroke, but I think it does.

Be optimistic. Most of the shark’s teeth on this beach are less than an inch long.

You have to pick them out from the crowd of sea shells, large and small, that lie

in profusion on the sand. If you go in with the attitude you’ll never find a tooth,

you won’t. I always have much better luck when I tell myself, again and again,

“Today I’m going to find some teeth.” The same holds for any project. If you start

off thinking you’re doomed, it’s going to become a self-fulfilling prophecy. Better

to affirm success from the start.

Look for patterns. All shark’s teeth have a roughly similar pattern. There’s a “U”

at the top where the tooth once joined the gum, and the pointed tooth

protruding from that. The teeth are glossy black and they don’t break when

tested with the fingers, like black shells will. Once you’ve found a shark’s tooth or

two, you can recognize the pattern much more easily. In business, you can use

your experience to spot patterns of behavior or circumstance that have yielded

opportunities or troubles in the past. For project folks, this experience can be

drawn from lessons learned sessions, risk management practices, or plain old

experience.

Be persistent. Some days you’re just not going to find a tooth, or, worse,

everybody but you is going to find one. Don’t let it get to you. Step away and

come back to it the next day. Keep after it until you succeed. I spent a week

looking for teeth one year and didn’t find one until the last day, when it tumbled

past my foot in the surf. Setbacks are going to occur in your work—accept that

fact and pursue success patiently, doggedly, with all the means at your disposal.

Enjoy the search for its own sake. Your work is a big part of your life. Don’t spend

it wishing you were somewhere else. Instead, give yourself to it as fully as you

possibly can; for every day you do this, your enjoyment will increase. Even if you

don’t find a single tooth, you’ve still got the surf, the sand, the blue sky, the

family—a whole range of joyes. Granted, it’s probably much easier to enjoy a day

of shark’s-tooth hunting on the beach than a day at the office, but that doesn’t

mean it’s impossible! Reduce stress and increase pleasure in ways that work best

for you. Take one-to-two meditation breaks throughout the day, take a lunch

break, go for a walk, get up from your desk and talk to people, listen to music,

whatever.

I hope these suggestions are helpful. Good luck!

http://www.pmportmanteau.com/


Neville Carson is a PMP and MBA who’s been managing technology projects and

products for over a decade by building strong relationships, communicating

effectively, and drinking plenty of coffee. In his blog, The PM Portmanteau, he

strives to share the results of his studies and experiences, along with a touch of

humor, for the benefit of product managers, project managers and professional

managers in general.

http://www.pmportmanteau.com/


PMI Global EMEA Congress, Dublin 2011

I’m back after some forced time out. And this time to give you an overview of

what went on on the PMI Global EMEA Congress, on May 9, 10 and 11 in

Dublin.This was my 4th EMEA Congress and the best yet: I assisted some

outstanding presentations and met some great people.

What is this Congress about?

This is the Congress that PMI sets up for the EMEA (that is, Europe, Middle East

and Africa). It consists of 3 days of presentations, a keynote speaker and lots of

networking. What I found out is that these EMEA Congresses are smaller than the

U.S. ones but richer because of the many countries represented there - and their

different cultures. The one thing you can be sure is that you're bound to meet

some great people there. So yes, I would recommend them for anyone whose

work is related to Project Management - and not Project Managers alone.

Before the Congress

Choosing which sessions to assist can be tricky and the timing doesn’t help: you

do that when you register for the Congress. On my first Congress I choose them

based on the title and topic. That, I can assure you, is not a good way to go. So I

asked the people I met there how did they pick what presentations to assist and

that led me to the process I now follow. It’s pretty simple, the first step is to

check who’s presenting. If I know the speaker, and I’ve been to a presentation of

his/her before and enjoyed it, then I sign up. If not then I go for the topic.

This process doesn’t give me the chance to assist all the best presentations but it

has both the reassurance of past experience and at the same discovering and

meeting some new speakers.

New to networking?

PMI enforces the need for networking. This was a downside for me as I believed

it was somehow faked - like showing interest in someone in advance so that later

on you could take some advantage of that relationship. But my views on this

changed now that I have some friends I first met in these Congresses. A first talk

with someone who you meet for the first time can be very fruitful. You can

actually learn a lot just by talking because everyone there has the same attitude:

they want to know why something that works for them doesn’t work with you,

what approaches are you using, what tough situations are you on and how you’re

dealing with them and so on. Of course you’ll find some people there where

there's no connection, some that are not all that sharp but at the end of the day

its well worth it.

To give you an example, this time I had the privilege to talk to Elizabeth Harrin

(actually she interviewed me for her blog "A Girl's Guide to Project

Management") and also Lindsay Scott from Arras People (she runs the blog "How

to Manage a Camel"). Don't miss them if you ever get the chance to meet them in

person.

The Keynote Speaker

This year’s keynote speaker was Kevin Eyres, former managing Director for

LinkedIn in Europe. He also enforced this networking attitude but to me it was

kind of short for a Keynote Speaker opening a Congress, specially when

compared to other Congresses. He positioned LinkedIn, Facebook and Twitter, he

showed how these tools have entered nearly everyone’s life and some LinkedIn

tools that are not all that well known.

Presentations

http://congresses.pmi.org/EMEA2011/

http://www.pm4girls.elizabeth-harrin.com/2011/05/video-diary-pmi-global-congress-emea-day-2/

http://www.pm4girls.elizabeth-harrin.com/2011/05/video-diary-pmi-global-congress-emea-day-2/

http://www.arraspeople.co.uk/camel-blog/

http://www.arraspeople.co.uk/camel-blog/

http://congresses.pmi.org/EMEA2011/


The presentations I assisted are listed below and I'd like to highlight some of

them starting with the Acropolis Museum. Theofanis Giotis is someone worth

listening to and he brought to Dublin a project of a lifetime indeed.

David Hillson is also on this category and the topic was a pertinent one.

Mark Gray offered a insight into risk management with the relations between the

risks themselves.

Jack Duggal belongs to the category of speakers worth listening to even if the

topic is boring and doesn't interest you. Curious enough, some of the things he

talked about were pretty much the same you can find on this blog: if you want to

excel in Project Management you have to go beyond best practices (but you

better know the tools and methods first). Check ScrumBut is a good thing after all

as an example.

Alfonso Bucero's presentation was also great, as usual. He focused on the

attitudes suited for Project Managers in particular all the while making sure

everyone was having fun.

And finally, Giusi Meloni. I didn't get to her presentation on the first day of

Congress but it was good enough for the Congress' organization decide to ask her

to do an encore, which I assisted. She did a brilliant job relating Alice in

Wonderland to Project Management.

Day 1

“Selling yourself and your Project to Senior Management” presented by Bernard

Faughey

“Business Change within Programmes: It’s not about transition” presented by

Omar Zein

“The new Acropolis Museum in Athens, Greece: A unique project of a lifetime!”

presented by Theofanis Geotis.

Day 2

“Learning the art of delegation” presented by Derek O’Brien

“Risk energetics: Developing renewable and sustainable Risk Management”

presented by David Hillson

“Systems Dynamics as a method for Risk” presented by Mark Gray

Day 3

“Project Mechanic or artist? The skills of a Project Artist” presented by Jack

Duggal

“Let’s get practical: crash with confidence” presented by Éamonn Kelly

“Your words, as a Project Manager, makes a difference” presented by Alfonso

Bucero

“Alice in Projectland: the adventures of a curious Project Manager” by Giusi

Meloni (encore)

And that was it...

Next year there will be another Congress, probably in Nice, France if you trust the

gossips on the topic. And I'll probably be there.

http://www.ah-ha-moments.net/2011/02/scrumbut-is-good-think-after-all.html



Part 05, Case Study - The Project Charter

This is the 5th part of "The Beginners Guide to Project Management" and the first

article to feature the case study that will accompany the rest of the guide. I tried

to make it as useful as possible to everyone (a generic example, industry

independent), so this project is all about moving your current office to a larger

new one.

This is presented in the form of a story, which is the best way I could think of to

learn something new.


Part 04 – What to do

Outputs and outcomes, again

The Project Charter, again

About scope

The “What” part

Alternative outputs

Wants and needs

You’re not planning



The Project Charter

Wants and needs

Why?




The Project Manager

Project success


Defining a project





Introduction





http://3.bp.blogspot.com/-OGkl0kn5bik/Td_ZHoNglDI/AAAAAAAAAcA/E1dfSkLWK8A/s1600/hands-on-wheel.jpg


When you arrived at the office last Monday your boss called a meeting to tell you

that he intended to move to a new office that would accommodate everyone.

The company has been growing fast for the last 6 months and it got to a point

where there was no more space available and the perspective of hiring more

people was real. In fact they have just started the recruitment process for 3 more

people. This all sounded very reasonable, just maybe late in the decision.

He then assigned this responsibility to you. Your first reaction was to find an

excuse:

- I don’t know the first thing about moving an office! I do Marketing projects,

that’s what I do know about...

He tried to pull you down to reality saying that a project is a project whether it’s a

Marketing, an IT or a health care project. Instead of arguing that each industry

had its own way of doing things, you realized that your boss was showing a great

deal of trust empowering you to do this project.

- Don’t get me wrong, I feel honored with your offer. I mean, it’s a big deal, it’s

something that will affect everyone and stay very present for a long time. But I...

Your boss cut you off. It was to be that way, you were the one responsible for

that project and that was it. And he ended the meeting.

Wow, that was simply too much for you to take on a Monday morning just after

entering your office. So you went outside for a coffee and a walk around the

block - something you usually do when you need to get a new perspective on

things. Two things were clear when you got back: (i) you were responsible for

that project (so you'd better get it right) and (ii) you had to learn a lot about what

was expected with that move. You didn’t even know the costs of the actual office,

so how could you know what would be reasonable for the new one? And the

location? And how big? And what were your boss’s expectations?

Second round

To address the first problem (the fact that you were designated as the project

manager for something completely new to you) you decided to first ask some

people for advice. You picked the ones that you knew well and that somehow you

figured that were able to give some useful pieces of advice. And of course you

also searched the web for templates to guide through the initial steps. This was

very useful as you found several guides in the form of question you should be

able to answer as a project manager - and get from others the answers you

couldn’t give yourself. You knew you didn’t know enough, but you were surprise

to see an objective measure of your own ignorance: on one of the templates you

checked, you were able to answer one single question out of 40! You really had a

lot to learn about this project...

You scheduled a new meeting with your boss so you could start getting some

answers, mainly focusing on the whys and whats. One technique you have used

in the past (with plenty of success but for Marketing) was putting questions in the

form of options that are either extreme or unrelated, like: "Would you rather

have an office downtown or in the countryside?" - extreme opposite options.

"Would you rather have independent air conditioning controls for each room in

the office or a small kitchen where anyone can warm and eat his/her lunch?" -

unrelated features. You figured it should work well for this project as these

questions were about exploring and not related to any field or industry in

particular.

The meeting took place on the next morning, Tuesday, and it was enlightening.

You learned that this move was expected to increase the company’s status (that

one never crossed your mind!) and there were some cash flow issues within the

company that prevented to take this initiative sooner (you'd never have guessed

that a growing business could have issues like that either). You also learned that

everyone on top management already knew you were in charge of this project.

And a recommendation to start talking to the financial department in order to

get an idea of costs related to the office.

After the meeting things were kind of crazy. For example, for the first time in the

3 years you worked there the CFO, the CIO and even the CEO actually stopped at

your desk for a chat. Of course you took the opportunity to check what their




expectations were and ask the CFO to guide you to the right people in the

financial department as you needed to check for the current costs on running the

office.

To cut this story short, you finally got to compile all the information you gathered

from everyone you talked to and started to work on the project charter that in

the end looked like this:

Project Charter

Project Authorization

This document formally authorizes this project to relocate our current office to a

new location. A project plan will follow to be approved by the Project Sponsor

and will follow the company standards regarding Scope, Cost, Time, Human

Resources, Risk, Procurement, Communication and Quality.

Project Scope

The purpose of this project is:

- to relocate this office to a new location in a premium area of the same city

- to increase to 150 the number of people that can work there

- keep all current conditions regarding parking, meeting rooms and open spaces

- keep the same costs of running the office

This meets both the company’s need of more office area and increase the

company’s image on the market.

The deliverables are:

- the rental contract for the new office

- new contracts for electricity, voice and data communications, etc.

- the actual physical moving of furniture, hardware, personal belongings, and

people

- the cancellation of all previous contracts (rental, electricity, voice and data

communications, etc.)

The Project Manager

The Project Manager is hereby authorized to interface with management as

required, negotiate for resources, delegate responsibilities within the framework

of the project, and to communicate with all contractors and management, as

required, to ensure successful and timely completion of the project. The Project

Manager is responsible for developing the project plan, monitoring the schedule,

cost, and scope of the project during implementation, and maintaining control

over the project by measuring performance and taking corrective action.

Milestones

- Approved project plan: in 1 week from today

- Approved selection criteria for the final decision: in 2 weeks from today

- Approved short list of 3 candidate locations: in 6 weeks from today

- Negotiation of the rental contract with the 3 candidate locations: in 12 weeks

from today

- Decision of the moving date: in 13 weeks from today

- Signed contract: in 13 weeks from today

- Actual move: to be announced

Budget

Due to the lack of experience, the budget is set based upon the last relocation of

the office 5 years ago, plus inflation, at 12.800€. This budget does not include the

contract with the new landlord nor the costs related to the time required by

some of the employees to the assigned to the project in the project plan that will

follow.


Project Charter approval

The next day you had a meeting with your boss who was also appointed as the

project sponsor. You sensed he wasn't all that happy with the reference to the

"company image" and the "premium area" in the Project Charter but you offered

that it was one of the project's objectives and that it certainly sounded better

than "improve the company's status". In the end he signed the Project Charter,

agreeing with everything in the document.

It was Wednesday afternoon and now you had a week to set up the project plan

and get it approved. You had some hard work to do.


Managing up

Affiliation link

Margaret Meloni has been here before with an Ah Ha Moment of her own. This

time I’m reviewing one of her products, “Managing up - The seven behaviors you

need to manage your management”. In fact, because of this particular product, I

decided to join her affiliate program and you can now use this link to check her

offerings.

About Margaret’s goal

Margaret’s goal is to help you, in particular if you work in Project Management,

to "end your day at peace and not in pieces". An ambitious goal, I should add. But

one that makes every sense. Why should you suffer to do your job right? Her

argument is basically that there are things you can do with your behaviour and

your attitude that can ease the pain.

About the “Managing up” package

This package contains a 21 page PDF document and 2 audio files. The PDF file

contains “Managing up” and Margaret’s view on managing your management,

you have an audio version of “Managing up” and you also have “Controlling

Yourself When Working With Jerks” which is a 53 minute discussion where

Margaret facilitates a talk under the topic of (surprise!) dealing with difficult

people.

Managing up

Margaret walks you through a story about these 2 real life persons who get

appreciated differently by their manager and she uses this story to point out that

some behaviours of yours will make you more appreciated by your management,

clients and colleagues. It’s not about how good a performer you are, that’s not

the difference between those 2 people. It’s about how you behave. In short,

Margaret tries to show you a way of being a role model to others by:

- putting others first

- communicating appropriately

- maintaining the right level of independence

- setting the right priorities

- be compassionate

- building strategic relationships

- setting your own boundaries

This may sound artificial or manipulative but it really isn’t. It’s about

“understanding what your manager wants and needs from you and manage

expectations in terms of what you need from your management”. It’s not about

getting your boss’s dry cleaning, it’s about making your boss’s job easier.

http://www.melonicoaching.com/

http://www.ah-ha-moments.net/2011/01/aha-skipping-change-management-is-poor.html

http://www.autowebbusiness.com/app/?af=1354468



Controlling Yourself When Working With Jerks

Margaret’s point is that if you respond to a jerk the exact same way he acts then

you also become a jerk. If you do nothing you’ll probably get stepped on again

(or not, sometimes it back fires on the jerk as Cornelius Fichtner pointed). What

you have to do is to find a way to neutralize the jerk, the situation where the jerk

can act or the impact of the jerk’s actions. Kind of applying Aikido (the martial

art) to business. Cool discussion and also some good stuff for you to think about.

Conclusion

The contents of “Managing up” is very useful to anyone working with people, in

particular to Project Managers. So my recommendation is for you to take a look

at Margaret’s products, I’m pretty sure you’ll find something that catches your

eye besides “Managing up”.

http://www.cornelius-fichtner.com/



Binfire: Project Management & Collaboration Tools

This is a review of Binfire, a hosted web solution for Project Management and

Collaboration. Binfire offers a free solution to anyone who needs to get a grip on

very simple projects. Very simple projects are, to my experience, the most

common projects. So I do hope Binfire is successful on they're effort to support

Project Management on an easy and intuitive tool.

This is the first review on Ah-Ha-Moments so some additional information is

necessary in order to understand how I've reviewed Binfire's software. This took

me a really long time (sorry for that) but I wanted to get a classification matrix

where I could map any piece of software. And this matrix had to have the ability

to grow (as I'm sure the needs I feel now will be different from the needs I'll feel

in 6 months) and still be able to compare the software's reach. So in the matrix I

put anything I could remember it could be useful - from really necessary things

like a Work Breakdown Structure to a Monte Carlo simulation which I've never

needed in my own projects.

Bottom line is that I really liked Binfire's approach although it's meant for small

and simple projects. But I do think some basic functionality is missing - like a

Work Breakdown Structure, for instance - that I hope they will include on future

versions. But hey, I've heard some basic functionality is also missing from

Microsoft Project which I believe is the most used Project Management software

tool! This is an important statement to make because the audience for this

software is an important thing to keep in mind. The fact that some functionality is

missing doesn't mean that the software is worth less. It just means that its target

audience is different.

Thumbs up for

Anyway, I really liked this software. First of all, they have a free version that has

some limitations but not linked to functionality. Then they have a really simple

and intuitive way of dealing with things that's really cool. And finally they were

really helpful each time I contacted them about some issue I found with the

software. Thumbs up for Binfire.

http://www.binfire.com/

http://3.bp.blogspot.com/-KnqdVo88md0/TftwiZIxaHI/AAAAAAAAAdE/nI3kWsLgTx8/s1600/pricing.JPG


Some of the things that were really cool about it are listed bellow:

Selecting just one person responsible for each task

Clever (and different) way of defining milestones

All changes are logged

Every time I contacted Binfire I had a great professional response: they corrected a bug I detected on the fly and they explained to me how things worked when I expected some other behavior from the software

Thumbs down for

Sometimes the things we're used to get in the way of the intuitive approach

Binfire has. Just to give an example, a milestone for Binfire's software is more like

a set of tasks. Although it's listed on the "thumbs up" section, I did have to

struggle a bit to understand how they were implemented. But these were not

problems with the software.

The problems I found were all related to the fact that the software is meant to

support basic Project Management activities - but very basic indeed.

No graphic display of the tasks sequence as task predecessors - come on, not even a Gantt chart?

There's nothing in the software to support costs: not variable costs, not fixed costs, and not EVM

There's no way to set vacations and holidays

Lack of reporting

Lack of importing and exporting functionality

Conclusion

If you're looking for some support for your Projects and if you have very basic

needs, you'll probably be happy with Binfire. I know I enjoyed playing around

with it. But if you need something more, even if it's just some place to register

costs associated to tasks, you better move on.

PS - Additional comment from Binfire

Binfire's development team works to improve the application daily and make it a

more productive collaboration tool. Coming soon, we will be releasing a new

version with a work breakdown structure in place of the current task and

milestone implementation. Also a Gantt chart with the capability of dynamically

modifying tasks & milestone is included. Subsequent releases will add a project

calendar & time tracking, along with many other features.

Follow Binfire on Twitter for updates @Binfire_info.

http://twitter.com/Binfire_Info

http://1.bp.blogspot.com/-w-k64sz_wsg/Tft8Bj3F_MI/AAAAAAAAAdI/w3MR36tLE_o/s1600/Milestone+history.JPG


Getting Things Done

It’s easy to support the argument that Project Management is mostly about

productivity and getting things done, right? What is not so easy to do is to

actually be productive. In order to do that you have to at least (i) know where

your headed (ii) have some process to get you going and (iii) check and reinforce

if where you’re headed is still where you want to be.

This article is about David Allen’s Getting Things Done which is basically a process

to get you going. And it works for me so it might work for you as well.

First things first

Any process such as Getting Things Done can work for your. Or not. If you have a

good process but you don’t know where you’re headed you’ll just get nowhere

faster. Although this article is about this particular process, I can’t stress enough

the need for the other 2 points mentioned before.

Next, a process is a process. It may work for you or not. But you can always adapt

things so they work for you. And you will always get some of the key issues

identified and addressed and so you will have something to gain from it.

The overall idea

Getting Things Done is a 5 step process:

1. Collect: Get all the stuff off your mind and into one place. 2. Process: Decide what to do with your stuff, is there actually something

you can do about it? Do it right away if it’s really fast. 3. Organize: Associate dates to tasks, are they urgent? 4. Review: Get an overview of what you need to do, is it too much to do

for that week? Can you do more? 5. Do: Take the time to do the things you have to do.

Simple, right? Now take a look at the process as represented below. You have

these 5 steps in there but it offers you a graphical view of the procedure: what to

first and what to do next. And see? You also get projects on this process! The

thing is a project in Getting Things Done is something you have to do that

requires more than one action, there’s no need for a Project Charter for these

GTD projects, OK? Same word but a different meaning.

http://www.davidco.com/

http://1.bp.blogspot.com/-JvlwXprQReo/TgRdl0JQUlI/AAAAAAAAAdQ/m_wUszbz1Dg/s1600/checklist.jpg


Collect

Your objective in this step is to get all your “stuff” in one place. Stuff also has a

special meaning in Getting Things Done: stuff in anything you have pending, it

can be physical, like a magazine that has an article you really want to read, or not,

like updating your shopping list. Now, the ideal thing is for you to get all your

stuff in one place but actually you won’t be able to do it because some stuff is in

your mind (and you can write a post-it note) and some stuff is a physical object

(like a company presentation’s hardcopy). In my case, I have 4 inboxes for my

stuff:

- my email inbox

- an inbox in a software I use (ThinkingRock) that implements Getting Things

Done

- a physical inbox at my office

- a physical inbox at my home

So what's the advantage of getting all your stuff in one place? Well, if you know

where all your stuff is, you can get your mind free enough to dedicate your

attention to what you’re doing. You won’t need to worry again about forgetting

something and you won’t need to keep making an effort to remember what you

have to do.

Process

The objective is to give a destination to your stuff that is already collected. The

destination can be just one of the following:

To Do: There’s an action you can take

References: It’s just something you want to keep for later retrieval, like a password or an article

Someday: It’s something you might want to do or that you’ll need to do in the future, but not now

Trash: Or, it’s trash and you throw it away

There is no other destiny to give to your stuff so you have to be sure on your

criteria to classify it. To illustrate this I’m going to share with you how I deal with

my email. I have no emails on my inbox at least once a day as I process my email

at least once a day (in fact I usually process my email on every chance I get).

1. If there’s something I should do about an email I label it with the categories that make sense for it and move it to a “To Do” folder - unless it takes under 2 minutes to take this action, in which case I do it immediately. This not just moving the emails to another folder (I could have a rule on my email to do that) - it makes me think about what to do next, what is the next action I want to take.

http://www.trgtd.com.au/

http://3.bp.blogspot.com/-91am2Ob9F4E/TgRfY2sB-xI/AAAAAAAAAdU/dc1fvFBGM6I/s1600/gtdworkflow.gif


2. If it’s something that requires no action from me but that I want to be able to retrieve it later on (like an email confirming the registration on some site), I label it and put it on a “References” folder.

3. If it’s something that I don’t want to take an action now (like something that has no importance whatsoever to me) I put it on a “Someday” folder.

4. On any other case, I just move the email to my trash bin (in fact, I have a folder named “Archive” that works as my trash bin).

So at end what will you get? A free mind and an empty inbox. In my case, this

gives me the ability to choose what to do next because there’s no obvious

pressure - not even an email in my inbox!

Organize

The objective now is to plan your work. You have a list of actions to do and a

certain time available. What is more urgent? What has a target date you have to

meet? What is more important to you? What is there to do that can be done

anytime? If you answer all these questions you’ll be able to:

Delegate the task

Schedule it to some date

Put in on a “Next actions” list

If you do this, you’ll get your work for the day (or week or whatever suits you)

planned.

Just one thing about urgent and important tasks. If you map urgent and

important on a graph such as the one below, you should, in general, focus first on

the urgent and important (I quadrant). Then you should focus on the not urgent

but important actions (II quadrant). Only after these you should worry about the

urgent but unimportant actions (III quadrant). These are the first candidates to

delegate. And discard every single time you can the not urgent and unimportant

actions (IV quadrant).

Now remember talking about headings on the beginning of this article? If you

don’t know what’s important to you and what you really value you’ll get a major

headache trying to sort out the importance of every single task you have. And

worst than that, if don’t know what’s important for you, you’ll get the other

things that you really don’t care about done first! This doesn’t look like a smart

thing to do, does it? Like Alice In Wonderland, if you don’t know where you’re

going any road will get you there...

Review

The objective is to make sure everything is aligned to your headings. In short,

http://www.ah-ha-moments.net/2010/12/lewis-caroll-on-planning.html

http://www.ah-ha-moments.net/2010/12/lewis-caroll-on-planning.html

http://3.bp.blogspot.com/-pSk_37g67mc/TgRlje49z5I/AAAAAAAAAdY/0JKfZ4HVnHk/s1600/urgent-important-matrix.jpg


your values are not static and so you should keep checking if what was important

to you last month is still important. Sometimes you get an opportunity that

dramatically changes everything. If you noticed, you only worry about one task at

a time. So if something comes up that changes other tasks, this is the place worry

about that. It's also time to check what's on your "Someday" folder. Maybe it's

time to take some of those actions.

One thing I don’t remember reading about that happens to me quite often is that

I get some duplicate actions. Suppose that someone told me about this book I

should read and I put it in my “Someday” folder. 3 months later I read in a

magazine an article about it and then I put it again in my “Someday” folder

because I didn’t remember it was already there. When you put things in a folder

you don’t check for duplicates, you just put it there. So this is when I de-duplicate

my actions.

So the benefit of doing this review is to keep you on track of what’s important to

you.

Do

This is what you wanted to on the first place, right? So just do it!

The advantage of this all this extra work is that:

Now you can do things without the stress of all the other things that are pending and the risk of forgetting something

You are sure you’re doing first the most important things to you

You can have an overview of what’s on your hands any time you want

Need more on Getting Things Done?

This is a quick overview of Getting Things Done. If I got you interested enough

and you're looking for more I'd recommend you David Allen's book, Getting

Things Done. If you want to get ahead fast, you can check this PDF flyer by Scott

Moehring, it's much more complete than this article so it should trigger in you

the need to find out more about Getting Things Done anyway.

I'm no Getting Things Done expert but I've been using it for some 4 years or so.

Because of this, this article is a hands-on approach on Getting Things Done, not

an in-depth guide. I hope you can make good use of it and become more

productive. By all means get back to me if there's something in this article that

needs some further explanation.

http://www.getrichslowly.org/blog/2006/11/06/getting-things-done-how-to-take-control-of-life/



Part 06, The Project Management Plan

This is the 6th part of the "Beginners Guide to Project Management" and it will

give you an introduction to the planning phase. It’s in this phase where you will

be able to give the most accurate estimates for time, cost, needed resources,

sequence the work and so on. So you will learn about several tools that can assist

you on doing this and learn what to focus on. Let’s start with a warning: a Project

Management Plan is not a Gantt Chart!


Part 05 - Case Study - The Project Charter





What is a Project Management Plan?

A Project Plan must give you 3 very different things:

An overall idea of how the project is to be managed (namely when to cancel it)

An increasing detail of the work to be done in all of the 8 project areas (Scope, Time, Cost, Quality, Human Resources, Risk, Procurement and Communication)

Estimates (of what you will deliver, in what time frame, with what cost and so on)

In the Project Management Book of Knowledge, page 443, it says that a “Project

Management Plan is a formal, approved document that defines how the project

is executed, monitored and controlled. It may be a summary or detailed and

may be composed of one or more subsidiary management plans and other

planning documents”. The bottom line is that the Project Management Plan is

something live that grows in time with detail.

Rolling wave

Thus the first concept, the rolling wave. It’s quite natural to have a greater level

of detail of what’s coming up next than the level of detail of what’s coming up in

6 months, right? So why not plan your project that way? Plan to the detail what’s

next and take only the time to plan an overview of what’s coming later, so the

tasks that are to take place sooner will have a greater level of detail. Does that

make sense to you? You’ll learn about some tools that will help you on this,

namely the Work Breakdown Structure.

Anyway, don’t get the idea that you will always plan in this manner. I’ve done

several short projects (like 2 weeks long) where all the planning is in place prior

to beginning the project work. The fact remains that most projects will benefit

from rolling wave planning.






http://2.bp.blogspot.com/-JTl7QhGddYA/TQZYLZGMezI/AAAAAAAAAUs/XG7r7LkNS5o/s1600/projwb2.gif


Requirements

A requirement is something that is needed and that your project should address.

You can always classify requirements into:

Business requirements, something that the organizations needs

Stakeholder requirements, something a particular stakeholder needs

Solution requirements (both functional and non-functional), are the requirements needed by the solution you’re developing to address the business’ and the stakeholder’s requirements

Transition requirements, are the requirements needed to take the organization from it’s current state to where they will be after your project is done but that won’t be needed afterwards. Just to illustrate this, you may have to migrate data from an old system to a new system and build a third system just to do that - and that third system will no longer be needed once all the data is in the new system. You can find a lot about requirements on the Business Analysis Book of Knowledge.

Relation between the project areas

No matter what you do, each project area (from scope to communication) will

impact some other areas. This is fairly plain to see: if you have to buy something

that you expect to take 2 months to be delivered when started planning the

procurement, you will definitely go back to your schedule and adjust it so it

reflects it, right? Same thing if it costs half of what you expect because demand

for that product broke for some reason. So there is no way you can separate each

one of the project areas and plan it alone, you somehow have to put them all

together or re-plan the previous planned areas each time you plan a new one. In

any case, you can’t follow a rule like “first do this then do that”. If someone tells

you they have a planning flowchart you can safely assume they’re either lying or

don't know what they're saying.

So how should you deal with that? I don’t think there’s an answer to that, and

this is why Project Management is so tricky. What you definitely must do, and

that’s what the Project Management Institute framework advices you to do, is to

take the time to double check if everything you planned for each of the different

project areas do fit perfectly - and they call it the “integration knowledge area”.

Conclusion

This was a preparatory article on what’s coming within the planning phase. The 8

project areas will be addressed in the following articles so it will take some time

before we move on to the next phase. By the way, project phases do usually

overlap a bit: you can plan a bit before you’re finished with starting the project

and so on.

And please remember: the plan is something to guide you and it's bound to

change. The plan *is not* something pre-agreed upon that you must follow

blindly!



Part 07, The Work Breakdown Structure

This is the 7th part of the "Beginners Guide to Project Management" and it will

push the planning phase one step further with the Work Breakdown Structure or

WBS. This technique is focused on what is to be delivered with the project, so it

seems like the perfect place to start. Basically, a WBS is just a hierarchical tree

that defines the entire scope of the project.


Part 06 - The Project Management Plan






What is a WBS for?

The main purpose of a WBS is to give a picture of what the project is all about by

showing all the deliverables. It’s not a plan, a schedule or an organization chart.

It contains only deliverables - not activities and tasks.

With a WBS you can also:

Cross check if you’re not forgetting something on your schedule

Make sure that everything on your schedule is contributing to some deliverable

Help you with the rest of the planning, including risk identification and even communication planning

Also, as a WBS is a bit static (much more static than a schedule anyway) it is very

useful for in-scope / out-of-scope discussions - if it’s not in the WBS it’s out of

scope for sure. Of course a WBS can change along a project but that should only

happen after some kind of approval process, even if an informal one. And

everyone at least in the project team should know about the scope change.

How to build a WBS

Although a WBS is usually a hierarchical tree, like an organization chart, you can

use whatever representation is suitable. One tool I use a lot for WBSs is a Mind

Map - with the great advantage of giving just enough detail as needed. Paper can

be fine too. Or you can use a Project Management tool such as Microsoft Project

- as long as you don’t confuse a WBS, a schedule and a Gantt chart.

To build a WBS you start with your project name. To give an example, suppose

you are to hold a fund raising event based on a wine tasting event. You could

start thinking about it on a time perspective, what to get done first. So you’d

probably start thinking about what you needed to get things started, then what

you needed to plan, the preparations for the event, what was needed to do to

setup everything, what was needed to do in the day of the event and to wrap

things after it was all finished. Oh, of course, and what Project Management







http://1.bp.blogspot.com/-LKs0VPEECSI/TWfjxUh8qLI/AAAAAAAAAZ8/_cn00BPpo4k/s1600/wbs.jpg


deliverables were needed. Here’s a possible WBS in the form of a Mind Map for

this project:


Other perspectives

You don't have to use a time perspective to build a WBS. You can also use a

department or functional (organizational) perspective, a geographical

perspective, a cost center perspective and so on. Use whatever suits your

particular project best.

Rules for building a WBS

Although this WBS looks very loose in the sense that it’s just a diagram / drawing,

you must take care and follow some basic rules so you won’t be sorry sometime

after. These rules make all the sense, but check them for yourself and check what

would happen if you failed to follow any of them:

Complete

Whatever you have in one level of the WBS, it must be exactly the same as the

sum of the level below. If the level below is just a detail of the level above, they

represent exactly the same thing, right?

8/80 rule

The last work package in any branch should take more than 8 hours and less than

80 hours to complete. This is just a rule of thumb, but it’s OK for most projects. If

you’re building a WBS for a 25 year project, this probably would make the WBS so

huge that it would lose its graphical impact, so be flexible with this one and do

take it as a rule of thumb. One way around this, and thus the use of Mind Maps

and collapsible branches, is to detail your WBS using this rule even in big projects

but to show collapsible models as fit so the WBS regains its graphical benefits.

Deliverables

The last work package in each branch should be a deliverable, not an activity or

task; and they should be represented by a noun, the name of the deliverable. But

http://4.bp.blogspot.com/-dY7M9wbH8LQ/TleFprk8DqI/AAAAAAAAAf4/GtqIJsTMZBA/s1600/WBS+2.JPG


specially if you’re building a time phased WBS, there could be “almost activities”

in the WBS in the sense of phases like planning, developing and testing. No

problem whatsoever, as long as you can tell them apart.

Decomposition

If a work package is decomposed, it has to be decomposed in more than one

work package. There’s not much sense in having a work package decomposed in

just another work package, right? That would be repetition, not decomposition.

100% of the scope

If something is in the scope of the project, it must be in the WBS and if something

is in the WBS it must be in the scope of the project; that is, the WBS must always

be a perfect match with the project scope. This is the most important rule and it

will allow you to use the WBS in many ways, including helping you schedule the

activities in your project.

Consistency

The used criteria for telling apart any 2 work package must be the same. May

seem just a detail but it does sound reasonable, no?

Conclusion

Although pretty basic, the WBS technique to represent the project scope is very

useful as it forces everyone involved to share the same view of the project. It can

help you along with the other planning activities and it has saved me many in-

scope / out-of-scope discussions. I must add that changing the scope of a project

so much that you have to change the WBS is not a bad thing, but you must know

that it is changing.

I use WBSs even in very small, 2 week projects. If not for any other reason, it sets

the ideas straight in my mind - and a small project must have a small WBS...


One way to lower the project overall risk is...

...to divide the project into phases! Have you ever thought about it? I didn’t until

recently, just let me tell you all about it and maybe you can challenge this idea.

Or come up with another idea.

This is no big breakthrough in Project Management but it was a great reminder

that no matter how much experience you have there is always a way to learn

something. I know I just did but...

...But first, some definitions

Let’s start stating the obvious for some but with a necessary definition first

anyhow to make sure we're all on the same track. Sub-projects or project phases

consist of the division of a project into smaller chunks where each chunk is

managed as a project itself. This last bit is the key to this: if you can manage a

phase as a project itself, then this phase must be quite independent from the

other phases in the project. And a project phase should always match a branch of

your Work Breakdown Structure (WBS).

Programs are different but easily mistaken for projects with sub-projects or

phases. In theory, a program is a set of related projects and it has outcomes

outside of the scope of each project. And usually some of the work within a

program doesn’t belong to any project in it.

In practice, a program is focused on business value and project on deliverables.

Why use phases in a project

You can use project phases for several reasons. In my particular case, I’ve used

them either to:

http://www.blogger.com/%28http:/www.ah-ha-moments.net/2011/08/beginners-guide-to-project-management.html

http://4.bp.blogspot.com/-2_zxIr9gxbI/Tl-NTeQe9NI/AAAAAAAAAgE/UbQAWNU7klU/s1600/trapezista.jpg

http://www.blogger.com/(http:/www.ah-ha-moments.net/2011/08/beginners-guide-to-project-management.html

http://3.bp.blogspot.com/-MTVvdNkX--Y/TmDlz_l-ZmI/AAAAAAAAAgI/9Ic1gbscCBw/s1600/ProjectPhase.gif


introduce a critical decision point in the middle of a project (like deciding if it’s worth to go ahead with the project after a feasibility study)

outsource part of the project work in the form of another project (which is a sub-project of the initial project)

and give the responsibility of that branch of the WBS to someone else (because part of the work must be done in a different geographical location)

In general, and it is also stated in the Project Management Book of Knowledge

(PMBOK), you divide a project into phases when you need some extra control to

effectively manage it.

But about risk?

I was recently working on a complex project involving 3 other organizations and

in that project no one believed that we would be able to get one of the

deliverables within the required timing (which would be a bummer). Now this guy

comes up with the idea of phasing the project putting this particular deliverable

into a different project phase. Well, first we checked if we could actually do it and

in fact that deliverable was kind of extra functionality and there was nothing in

the project that depended strongly on it, so we all bought the idea and went for

it. And we sold it to senior management that we would be safe if all the rest was

delivered on the required timings. This particular extra functionality was then

seen as a bonus, no bummer anymore!

So in short, we took the tree branch of the WBS that we expected to crash

somewhere in time and isolated the problem. This may sound like escaping from

one's responsibilities, but it isn't. It's about keeping the damages under control

on one side (reducing the risk impact) and on the other side providing more

means of management (reducing risk probability).

Conclusion

If you take another look at the reasons I presented earlier for phasing a project

and the PMBOK definition, they also imply the possibility of lowering the risk

associated with the project. In the case of the PMBOK definition, if you have

more control over the project you have less probability of things going wrong,

right?

So in fact this is not a new concept at all, but it was the first time I’ve seen it and

applied it clearly: phases as a means to lower the overall project risk.

Now I’m a curious person: in your case, why have you used project phases? Have

you ever done it to reduce the project overall risk?

Images from http://www.radio.rai.it, http://www.leadwithhonor.com

http://4.bp.blogspot.com/-2_zxIr9gxbI/Tl-NTeQe9NI/AAAAAAAAAgE/UbQAWNU7klU/s1600/trapezista.jpg


3 Myth Busters on Delegation

Delegation is not a new concept so why an article on the topic? Basically,

because different people mean different things when they talk about delegation.

And delegation is important, right? It allows you to do more than you would be

capable on your own, right? But do you know how to do it? When should you do

it? And starting from the start, do you know what delegation is? You’ll find 3

myth busters on this article but before that...

What is delegation

...let’s make sure we’re all on the same page and start with a definition. If you go

to Wikipedia, delegation is defined as:

(...) the assignment of authority and responsibility to another person (normally

from a manager to a subordinate) to carry out specific activities. However the

person who delegated the work remains accountable for the outcome of the

delegated work.

Accountability here is key, that’s something you don’t delegate ever. And this

definition is also very useful to show the difference between accountability and

responsibility. More over, in some languages like Portuguese, there’s a single

word for both concepts which can be very confusing.

So this definition seems like a pretty good start but it’s somehow misleading.

Picture this: you are a Project Manager and you assign a project task to a team

member who has the perfect set of skills to carry out that task. My trick question

is: are you delegating? If you go back to the previous definition, you are in fact

delegating but somehow it doesn’t sound right, does it?

The reason why it doesn’t sound right is because you don’t delegate tasks that

people are supposed to do - when you delegate you’re giving someone tasks that

are outside their set of skills, job description or whatever. By outside I don’t

mean the complete opposite (in fact that would probably be a dumb thing to do),

what I mean is that the set of skills required to do the task is not a perfect match

with that person’s skills.

Why delegate

And this links to why to delegate. Why should you give someone a task that

he/she is not the perfect person to do?

Myth buster #1: you don’t delegate to get more done!

http://en.wikipedia.org/wiki/Delegation

http://2.bp.blogspot.com/-l1HOyVmy81s/Tmo9xe7RF9I/AAAAAAAAAgg/xyWzm0EpH_g/s1600/Delegation.jpg


Because if you did delegate to get more done, you’d delegate to the perfect

person to do the task, just like you do when you assign project tasks to team

members - in fact, this is what Project Management is all about, getting things

done! That’s why assigning projects tasks is not delegating. Of course you can

assign tasks to people who work for you and are perfectly capable of doing it but

that is just not delegating. So we come to the fact:

Myth buster #2: You can only delegate to allow people to grow professionally

Any other purpose would be assigning tasks (or something else) but not

delegation. Let me give you an example to ilustrate this statement. Suppose you

have a team member who is interested in Project Management and both you and

his/her boss think that he/she has the capabilities and a chance to become a

project manager. Besides formal training in Project Management, you could give

him/her a taste of what project management really is by delegating some of your

tasks as a project manager to him/her.

In this case, the benefits from delegating would be:

Testing the team member’s interest in Project Management

Grow the team member professionally

But you also costs alongside these benefits:

Time to explain and to guide the team member

More risk on that task as the team member’s skills don’t cover all the skills required to do the task

So there you have it, there is a cost linked to delegation! The exact same thing

could happen if you think of promoting someone: why not give him/her a taste of

what’s to come and have that person do some of the tasks he/she will do after

he/she is promoted but currently doesn't?

Defining delegation again So how do you define delegation? Try this one for size:

Delegation is giving a task to someone with the purpose of that person’s

professional growth - that person gets the responsibility for the task but

accountability is always yours.

What to delegate

Now that you have the whys clear on your mind, what should you delegate? To

answer the whys requirements, the task you choose to delegate should be:

A challenge, just a bit harder than what you think your team member is capable of - so your team member can learn something

Something your team member is capable of doing with your support - if you ask for the moon your team member will lose every bit of motivation

Something in the direction your team member expects in his/her career path - or the purpose is lost

Stuff you like to do yourself, as your enthusiasm will sure be noticed by your team member and probably motivate him

Which leads us to:

Myth Buster #3: you don’t delegate what you don’t want to do yourself!

In a nutshell, you have to find something that makes your team member want to

http://www.ah-ha-moments.net/2011/06/getting-things-done.html



do your work. It’s not all that easy.

Conclusion

Keep in mind these myth busters:

#1 you don’t delegate to get more done

#2 you can only delegate to allow people to grow professionally

#3 you don’t delegate what you don’t want to do yourself

I’ll soon post the hows on delegation which will give a hands on approach on

delegation. But if you want a jump start, check out Gregory Smith's guide on

delegation "How to delegate effectively" and "Successful delegation" on

MindTools, both free of charge. They're not the approach I'll be talking about but

still they focus on the essential things about delegation.

Images from http://www.ideasandtraining.com

http://www.careerknowhow.com/delegate.htm

http://www.mindtools.com/pages/article/newLDR_98.htm


Delegation How To

I wrote previously about delegation closing with a couple of links to articles that

offered a process to guide you. There are quite a few approaches on how to

delegate but there’s one I like best. This article is a how to guide to this 8 step

delegating process that I like best. And you can, for instance, use it with those in

your team that you think are ready to take on other assignments. Or more

generally, you can use whenever you have someone that is ready to evolve to

some new ground.

Step 1: Pick your delegate

The first step is to decide who needs to grow, in what direction and where your

delegate stands at the moment in terms of the required capabilities and skills.

Just a quick parenthesis: I had some trouble picking the word "delegate". My first

pick was "victim" but it has a strong negative connotation. Then I thought of

"target" which was OK as long as you took it in the sense of objective. But then

you could also take it as a target to shoot at, not exactly what I had in mind.

Anyway you can try these alternatives and read this article using independently

the words "delegate", "victim" or "target".

Now back to business. You probably have someone working for you that

somehow you feel like he/she is the perfect delegate but think about it: Does

your delegate really wants to grow? What would he like to do in a near future?

How far away is he from that? How much time do you have available to dedicate

to him? Is your delegate the kind of person that likes being closely guided and

told what and how to do? Or is he very independent? Does he has enough time

to take on a delegated task? Will he be willing to take it? How much will he have

to learn? Can you decide alone on his allocation to a task or is he doing some

work on another project?

In a nutshell, you should do some investigations in the following directions:

career path, skills and capabilities, availability, accessibility and motivation.

Take a couple of minutes investigating in each of these directions asking yourself

questions such as the previous ones.

By the time you end this step you should have a clear view of what your

delegate's needs and expectations are and this should help you on the next steps

putting everything into context.

Step 2: What to delegate

One thing I see a lot is people delegating tasks that are unimportant but urgent.

The reason for this is that when you do it you get more done. I couldn't agree

more but unfortunately that is not delegating, that’s assigning tasks. If you do

want to delegate, please delegate tasks that:

have to do with your delegate’s growth,

should have little impact on you whether it gets done right or not,

won’t take away from you more time than the time you have available,

and you’ll get a big bonus if the task has visibility and if it’s something you enjoy doing yourself

http://www.ah-ha-moments.net/2011/09/3-myth-busters-on-delegation.html

http://2.bp.blogspot.com/-b4wNR9LEU3o/TnNrLwBhx7I/AAAAAAAAAgs/aqBcW7i4Zdo/s1600/growth.jpg


Step 3: Define your desired results OK, so at this point you have a delegate and a task. It’s time you think a bit on

the possible outcomes or results: the one you want, what would be acceptable

and what would kill the process. Are you willing to take the risks involved? If you

are, define your desired results in the most objective way you can. You have

some ways of doing this, maybe the most popular is using the SMART objectives.

But one that fits perfectly in this delegating process (and I only learned about it

earlier this year) is the MORE objectives. Like the SMART one, it’s an acronym

and it stands for Measurable, Observable, Relevant and Example:

- Measurable: get specific stuff like dates or numbers that you can easily

measure and that relate to the task end results (like how many pages should the

report to have or when should it be ready)

- Observable: this is focused on the behaviours are you expecting to corroborate

the task was done as you desired (did you get any feedback on that report? did

someone ask for a more in-depth analysis on a particular topic?)

- Relevant: Why is the task important? Why should it matter to your delegate?

Why is it important to you?

- Example: it’s very useful to show a similar result, if it’s a physical one even

better ("Hey, I have the same report for last quarter, take a look at it to get you

started", you might say)

Step 4: Sell the task This is the key step of delegation: you have to make your delegate want to do

this task and come back to you asking for more of the same. If that ever happens,

you’ll know that you're really delegating. And it’s now time to talk to your

delegate about the task you want him to do and sell it to him. I confess I’m not

much of a seller, but still it’s a good start if you center the conversation on your

delegate and answer basic questions like "what’s in it for me", "will I get a bonus

at the end". You could explain how much you’d like to do it yourself, how

important it is for the organization, that many people there would like to be in

his shoes just to be responsible for that task. One thing that helps is delegating

tasks that you wish for yourself, that puts some excitement when you talk about

it that you just can’t hide.

Step 5: Communicate authority When you talk to your delegate to sell the task you should take the change to

make clear how much room for manoeuvre he has. This alone will prevent your

delegate to (i) come back to you with just about anything and (ii) go too far and

get into where he shouldn’t.

This is necessary but not enough. You should also communicate that new

authority to at least (i) the person who asked you for that task and (2) the people

your delegate will need to do it. Again, this will open some doors to your delegate

that are usually closed.

Step 6: Establish a deadline Suppose you don’t have a time frame for the task. As most people will take as

much time to do something as the time available to do it (that’s called the

Student Syndrome), you’ll never have the task done. And you don’t want that. So

negotiate with your delegate when he should give you the task’s results.

Negotiating is generally a good idea as it’s possible that you don’t know how

much is going on with your delegate even after the initial assessment on Step 1.

Step 7: Negotiate follow-up The amount of control you need on the task being done depends on:

http://en.wikipedia.org/wiki/SMART_criteria


- The distance between your delegate’s skills and capabilities and the ones

required by the task

- How much is at stake with the task

- If your delegate is an independent person

So negotiate with your delegate how you both should follow it up and both be

happy about it.

Step 8: Provide feedback At least after the task is done (depending on how you agreed to follow it up) you

must take the time to give some feedback to your delegate on how he met the

objectives. This will allow your delegate to:

Know what he did right so he can keep on doing it (remember that if he’s not used to that kind of work so he probably won’t recognize that easily if he did it right or not)

What he did wrong

What he could do better

If you’re no expert on feedback, think of it like a sports coach. What a coach does

when giving feedback is showing evidence (like a video) of what his/her athlete is

doing well (like passing the ball to where the other player will be) and what

he/she is doing wrong (like looking at the floor when he has the ball - and not

looking straight). The coach exposes some negative stuff but he does it as a fact

and shows evidence, his purpose is obvious: he is trying to make his athlete a

better one. And so they listen to what he has to say and actually try to take on

his advice as they do want to get better.

Conclusion

This is a guide to delegation that is pretty straight forward and easy to follow -

there’s no rocket science here. Just don’t forget that delegation is frequently

mistaken with assignment - as long as you can make the distinction you’re safe.

You can check the previous article on delegation if you need some background on

it.

When you start delegating in a specific direction with a delegate you will

probably see a clear evolution of the delegate: he will be more and more

independent and confidant. As this happens you can gradually give him more

complex tasks, more autonomy and more responsibility. And continue doing it

until your delegate is ready for his new assignment, promotion or whatever you

were preparing him to initially. But do it someday, you can’t keep delegating

forever, can you? Not on a single delegate.

And finally, even if you're assigning tasks and not delegating them, there are a

few ideas in this article that you can use.

Images from http://seanlgriffith.wordpress.com

http://www.ah-ha-moments.net/2011/09/3-myth-busters-on-delegation.html



Part 08, The Gantt Chart

So now you know precisely what is to be done: it’s all in the Work Breakdown

Structure (WBS). Now comes the how. How are you to do the things you’re

supposed to deliver? What activities are necessary to get the results you need?

How long will they take? Who will be responsible for which activities? Which are

the necessary skills and competencies? Is there a particular sequence you need

for the activities?

You can put all these into a chart that most people (people in general, not Project

Managers) find mandatory in Project Management: I introduce you the Gantt

Chart!

About Gantt Charts

First a word of warning: Gantt Charts are not all that necessary! Please keep that

in mind for the rest of this article. But... In order to build a good Gantt Chart

you’ll have to go through a lot that puts all the hows together in your mind. In my

particular case, I use them a lot mostly for communication purposes like

presentations and reports. A Gantt Chart is well understood by most people not

into Project Management (it’s very graphic and somehow pictures are easy to

understand) and I find it a very effective tool. It can be really powerful. The point

is, the importance of a Gantt Chart is not the chart itself but what you have to do

to get it. If you don't need it forget all about the Gantt Chart - except the steps to

build it. And that's the reason why it's on this Beginners Guide.

Oh, and Gantt Charts also have an history that is worth checking if you're into

these kind of details.

Defining Activities

The first thing to do to develop your Gantt Chart is to define what activities are

needed in order to get the deliverables you need for your project. If you look at

your WBS, you’ll find all your deliverables on the bottom of each tree branch.

Remember that if it’s there then it’s something you have to deliver; and if you

have something to do in your project that doesn’t fit any of those deliverables,

then it isn’t your project’s work.

Now suppose you have a deliverable “Hardware”. That is what you have to

deliver. Take that deliverable and think about how you’ll do it. Instead of a noun

like “Hardware”, you should get verbs like “Agree on tech specs”, “Order

hardware”, “Deliver hardware” “Install hardware” and so on. These are your

activities.

Don’t worry if you find out that you have to change your WBS because you forgot

something. Although I’m presenting these planning steps one at a time you will

go back and forth between them frequently. Planning is always an iterative

process. Also the order in which you approach activities is not fixed. In fact, and

in particular in small, simple projects, I usually do all of these steps at once, going

through all the steps for each activity, one at a time. Any way you do it is OK as

long as you do it and feel comfortable with it.



http://en.wikipedia.org/wiki/Gantt#Historical_development



One way to do it is to put all of your WBS on some Project Management software

that can produce a Gantt Chart (you can check some free software on the

Software Directory) and add the activities for each deliverable there. You can

also start to add some information on these activities like the skills and

competencies or even the resources you need for carrying them out. But don’t

focus too much on the people unless you already know for sure who will be in

your project team.

In longer projects or projects that you have to take one step at a time (like

Business Intelligence projects) it is also a good idea not to worry too much about

getting all the activities for all the deliverables listed at once in an exhaustive

way. The reason for this is that if you don’t know exactly what’s ahead in the long

term so why worry now? This kind of approach is called rolling wave planning:

you detail what’s coming up next and keep the rest that's further in time with just

enough detail to have a wide picture. In very dynamic projects this is also valid: in

6 month the context (technology, business, economic,...) is significantly different

- that's why it's called a dynamic project - and require then different activities.

Sequencing Activities

The next step is to sequence your activities when you have a mandatory order

(or maybe a best practice or an organization policy that works as mandatory for

your project) that must take place. In this “Hardware” example, it’s pretty

obvious that you you cannot install the hardware before before it’s delivered and

you can’t have it delivered before you order it. This is the kind of sequencing you

should focus on.

And don’t forget that the activities for one deliverable can impact other

activities for other deliverables. For instance, and going back to the "Hardware"

example, you can have another deliverable “Software”. In this case you probably

will have to install the software but you need the hardware first, right? Don’t

forget these dependencies, you can’t look at the activities for each deliverable

separated from the rest of the activities. And make them explicit, no matter how

obvious they are to you.

Estimation

And it’s now time to estimate durations and resources (human and equipment):

and those durations and resources are always related: more resources usually

translate into a shorter durations. At this point in time you may know (or not)

who will be in your team. If you do, great. If you don’t, think about skills and

competencies so that at the end you can say something like: “I need 1 database

administrator, 3 programmers and 1 web designer in my team”.

Depending on your project, this estimation job can even be done by people that

only do this - this is probably your case if you're in Civil Engineering. Or you can

ask the people who will be responsible for the activity to estimate its duration

themselves (the Agile way). Or you have enough knowledge about it yourself to

provide an estimation. Or you can say “the average time we take to buy new

hardware of this type is 4 weeks” and use it. As long as you feel confident about

the estimates you use you’re on the safe side.

What you shouldn’t do is something like “a building takes 6 to 18 months to build

so I’ll give 24 month as an estimate and play safe at the same time”. This is wrong

because:

you’re not estimating activities but the whole project,

it's almost with a gut feeling,

you’re hiding a buffer, and

you’re not comparing the building in your project to another one done recently and in the same conditions, materials and so on

And you shouldn't guess. Or try to have exact values (that's why these are called

estimates).

http://www.ah-ha-moments.net/p/free-software-directory.html



And you're ready

If you add a start date, holidays, vacations (if you have a team ready to go),

planned absences like training and weekends you get yourself a schedule to

guide you. And all this information put together in such a layout is called a Gantt

Chart!

You must have seen it before if you've reached this far in this guide, haven't you?

Conclusion

Use a Gantt Chart if you need to:

set your own ideas straight or

to communicate.

It’s a great tool for these purposes. And later on it may even help you in some

other ways that I intend to write about when we reach the Control stage. Just

don’t take a Gantt Chart for your project: your project is your team, your

deliverables and your stakeholders. These come first. They always do.



There's No Such Thing as "My" Project, by Michael

Greer

Most project managers don't start out their careers thinking they'll be project

managers. Most of us start out as specialists in a field that we love. In my case, it

was instructional design and development. For others on my teams it was media

production, computer programming, technical writing, performance analysis,

systems design, engineering... even marketing. We all began our professional

lives trained in a unique discipline and were secretly thrilled when someone hired

us -- trusted us! -- with the responsibility to practice our unique specialty in their

organization. The best among us are a bit perfectionistic. We willingly put in long

hours to "get it right" and to polish and refine our contributions. The best of us

can remember how the hours seemed to fly by as we created, privately reviewed,

adjusted, revised, and refined our professional work products until they were the

absolute best they could be.

And this eventually got us recognized. We became the "go to" person who could

handle the tough challenges. We became the one who could solve those

professional puzzles, finishing with a flourish like a rodeo cowboy tying off the

legs of a roped calf, stopping the clock in record time, arms raised in victory and

waving at the crowd. We became local hereos.

And what did this incredible track record earn us? The chance to lead a team of

our own. The chance to work our magic with the help of a whole bunch of our

fellow professionals.

Yes, every project manager can remember that moment when it all changed --

that moment when they were called into their supervisor's office and told that

their record of individual victories had earned them a team of their own. I

remember when my first big PM opportunity came. I remember stifling my

Homer Simpson-like "Whoo Hoo!" and summoning up my most confident Mr.

Business serious face and telling the boss that she had nothing to worry about.

We'd get it done... and done right. [Gulp!]

As the years rolled by, it turns out that I was a fairly good project manager.

Because I had first-hand experience struggling with the same issues and meeting

the same deadlines as my team members, I could empathize with them,

anticipate their problems, accommodate their needs, and generally serve as their

advocate to keep things running smoothly. And the best part of my PM was that

my professional judgment had been years in the making. I knew what quality

was. I demanded it of myself and I demanded it of my team. And together we all

produced deliverables we were professionally proud of.

Eventually, I left the consulting firm that was my employer and started my own,

independent consultancy. It wasn't long until I was developing bids and

competing with the big guys. And to my surprise and delight, I was winning

http://4.bp.blogspot.com/-vIt9YUeI6lI/ToXwenkeWAI/AAAAAAAAAhA/z6-bo5W55SA/s1600/MichaelGreer.gif


contracts!

One client in particular was a major multi-national tech firm with whom I

contracted for nearly a decade. And it was early in my relationship with this firm

that I had my major "ah-ha" moment.

Here's the deal: My center of gravity -- my core -- was my ability to carefully

analyze, prescribe, design, and develop excellent training systems that supported

the client's new products. These training systems helped their sales people,

customers, installers, and support reps get these highly complicated devices

installed and keep them running smoothly. I hired smart PhDs and super-techy

specialists and some of the best media people our money could buy. The bottom

line: We did really good work and became a top-choice vendor among vendors

for this client. They gave us plaques and awards for our jobs well done. And we

took enormous pride in our work

After several years working with this client, we got to know their staff fairly well.

We knew who we preferred to work with and we knew who could be a pain. So

when it came time to design one particularly complicated project and I learned

that one of the biggest pain-in-the-neck client reps was to be a key player, I

pulled out all the political stops and simply designed our project around her. I

assured our main client contact that we would be just fine without her input.

As the project unfolded, our new pattern emerged: We (my team of professionals

and I) became the self-contained experts that we had gradually evolved into in

this organization. We told ourselves we knew best what was needed and took

responsibility for creating it. In the meantime, our pain-in-the-neck nemesis was

watching from afar... tracking us... quietly building her case for blowing

everything sky-high. I heard rumors about her disagreeing with us, but I dismissed

these. After all, it was our project -- she had been neutralized early on by my

management end-run. So, really, what did her opinion matter?

When it came time for our developmental (beta) test of the training, she finally

emerged from the shadows. She managed to insert her people into the test and

do everything she could to discredit our design. She went public with her own

analysis and set of recommendations. Powered by the rage of having been

marginalized for so many months, she pulled out all the stops and brought the

project to a grinding halt. Vast amounts of money and months of labor on the

part of many people were thrown out the window as we were forced to start

over. This time she would pick the team (another vendor) and this time her voice

would be heard.

News of this incident spread throughout the client organization. A professional

reputation that had taken us years of overtime-laden, perfectionistic effort to

build was now in question. My bids were no longer slam dunk wins, but instead

got extra scrutiny and took extra effort to defend. In short, this one woman and

her supporters had really knocked us down a peg or two. And while we would

eventually climb back up a little, we would never again have the unquestioned

credibility we once had.

So what's the "aha" here? Well, this painful incident produced several. The main

one is this: There's no such thing as "my" project. There is only "our" project. All

the stakeholders who matter must be engaged and participate in a way that they

find satisfying. In my hubris (in my whole team's self-contained pride), we had

developed a "we know best" belief and tried to marginalize an important person.

I simply didn't want this woman mucking about in "my project." The result is that

I was able to ignore and suppress her in the short term, but in the long run it all

blew up in my face. Truth is, it never was solely "my project." It should have been

"our" project and I should have engaged her in a meaningful way on the team.


Which brings me to another "ah-ha." A project manager is not there to be the

resident expert. A project manager is there to be a facilitator among experts --

someone who "teases out" of the client and the specialists on the team a

mutually areed-upon and team-executed set of deliverables. It is an arrogant

indulgence for the project manager to think his vision, exclusive of other key

stakeholders, is the perfect solution. In fact, there is no such thing as a perfect

solution. There is only a shared "best we can get" solution that reflects the inputs

of all the important stakeholders.

In the end it comes down to this: I became a project manager because I was good

at my particular area of expertise. But I succeeded as a project manager because I

was able to let go of my role as the smartest guy in the room and adopt the more

important role of the guy who facilitates an entire team full of "smart guy"

contributions. In other words, I became a real project manager when I began to

derive my greatest joy from synchronizing an amazing team effort instead of

hogging the spotlight as a soloist. And while this transition can be a difficult one,

it can lead to enormous professional satisfaction as you enlist the efforts of many

good people to create something that transcends them all.

Posted by Michael Greer. Michael is th author of The Project Manager's Partner,

The Project Management Minimalist and other PM books. He creates and

presents customized, on-site Project Management workshops and provide other

consulting services. His current professional passions are:

1) Simplifying PM for PM newbies through my Project Management Minimalist

books, videos, audios, webinars, etc. More details here

2) Shining a light on useful, absolutely free, no-strings-attached PM Tools,

Training, etc. through my blog Project Management FREEBIES. More details here

For lots more info, visit Michael Greer's website or email him.

http://michaelgreer.biz/?page_id=2

http://michaelgreer.biz/?page_id=1668

http://www.michaelgreer.biz/pmfreebies/

http://michaelgreer.biz/

mailto:[email protected]

http://4.bp.blogspot.com/-vIt9YUeI6lI/ToXwenkeWAI/AAAAAAAAAhA/z6-bo5W55SA/s1600/MichaelGreer.gif


How to give feedback

Feedback is crucial for Project Managers, both giving feedback and receiving

feedback. The sooner a Project Manager has feedback the sooner he can react

and change things for the better. And the sooner a Project Manager gives

feedback to his team the faster they will start performing better. The question is:

do you know how to give feedback? Or do you do it like this guy in the photo?

Set the scenery for feedback

There is only one reason for you to give feedback: to increase performance both

by (i) correcting the bad things being done and (ii) making sure people know

what they’re doing right so they do it again and again. If you’re thinking of giving

feedback for some other reason, it’s not feedback you want. So always keep this

in mind: the only one reason for you to give feedback is to increase your team's

performance.

Feedback can also play a part in a bigger picture like in delegation. If you use

delegation to develop your team’s skills and competencies, then feedback is

mandatory in that process.

In order to show how this feedback thing works, I’ll compare you, a Project

Manager, with a sports coach - say a basketball coach. Now a coach just wants

one thing: he wants his team to win. And to win he has to have a team

performing at its best. Isn’t that what you as a Project Manager want from your

team? Also, coaches use feedback all the time, that’s a natural thing for them and

for their teams and players. That’s probably why Ken Blanchard once said that

“Feedback is the breakfast of champions”.

One issue rule

One issue at a time is a golden rule on feedback. You can't turn a team used to

losing to win the championship in a day. It takes time. Explain that to your team

and make sure they understand it so they don’t bring everything to the table at

once. If you discuss several things at the same time people won’t understand the

relative importance of each of the things you just talked about. So why did you

talk about the less important ones? Focus on the most important thing you want

your team to do better (also called negative feedback) and the one you want

your team to keep on doing (also called positive feedback) per session. Then

move on to the the less important ones ranked on your list for the next

conversation, and keep on doing it. And don't forget to keep your list updated,

OK?

Focus on facts and analysis

Giving feedback can easily turn into a difficult conversation charged with

negative emotions. The best you can do to prevent it is to focus on what really

http://www.ah-ha-moments.net/2011/09/delegation-how-to.html

http://en.wikipedia.org/wiki/Ken_Blanchard

http://1.bp.blogspot.com/-C9omK2Liqe0/To8q5--gFbI/AAAAAAAAAhQ/IkM2dkeajSw/s1600/coach-yelling-at-athlete.jpg


matters and that is facts - that's what you want to change. In a basketball team

you can easily imagine the coach using a movie to point out these facts (for

instance, to analyze the cause of turnovers). If you use facts and analyze them

together with the team it’s much less likely that someone gets offended or

somehow over reacts.

It’s very important that you stick to facts and even more if you’re giving feedback

on behaviors - which is, from my experience, much more common in Project

Management. If giving feedback is difficult for a coach analyzing turnovers

imagine giving feedback on someone’s bad mood. In such cases the best is to

show a direct relation between cause (for instance, not saying good morning

when entering the office) and consequence or impact (other people think they

did something wrong and you’re angry because of that). Focus on the impact is a

must in such cases. And by the way, you can stress the impact in any case, even

in simpler feedback scenarios like the cause of turnovers in basketball - where

the impact could be a counter attack and 2 more points for the opposite team.

Now suppose you focus on opinions and wishes instead. Or you’re critical. Do

you think it would help in any way if the coach told his team “I wish you didn’t

lose the ball so many times” or “did you leave your brains at home before coming

to the game?”. Does it give a hint to a solution for the problem? Does it even

state what the problem is? It doesn’t show anyone what they could have done to

prevent the turnovers, does it? Worse than that, it leaves the door open to

arguments that won’t help in any way because if they don’t see what they did

wrong they can easily assume you’re just picking on them, right? It seems it

wouldn't help much on increasing your team performance... Oh right, and that's

what feedback is about, again: the only one reason for you to give feedback is to

increase performance.

Give positive feedback

Assuming you’re giving feedback to make your team better, it’s essential that

you give feedback on what your team is already doing right because that’s the

only way I know of of turning it into a habit. On an extreme position, team

members can think that they’re not doing a thing right - just because you didn’t

say it. It also helps the message “I’m giving feedback to increase your

performance” to gain credibility because you’re showing what the team did that

contributed to the end result. And so, these feedback talks become more likely to

be accepted by the team members; and make them participate and speak their

minds.

One other thing about positive feedback: it's a good idea to start giving feedback

with positive feedback first and then negative feedback. The reasons for this are

the same, people accept better something they need to do better if you tell them

first what did well.

Give room to reactions

And this leads to the team finding ways, by themselves, to correct whatever

problems you’re trying to solve. And I can assure you that many times (at least in

Project Management, not sure if it works the same way in sports) teams come up

with much better solutions than the ones you have - for the simple reason that

they’re the ones in the field and they’re perspective is different from yours

because of it. So take the steps you feel necessary to involve the team and make

them at ease and speak their minds.

On the other hand, if you give feedback like you’re criticizing or issuing a verdict,

you’ll kill any discussion before it even starts. So be open, think out loud and

involve the team - let them say how they feel about it, what caused them to do

it, what they think they can do differently and so on. Be open about it, from start

to end.

Use concrete examples


The more concrete and specific you are the more likely you are to have people

understand (i) what they did and how to do it better the next time and (ii) how to

repeat again and again something they did really well.

If you say “a ball must be passed to where the other player will be, not to where

he is when you pass the ball” is one thing. But if you show on a video how the

other player couldn’t catch a particular pass, I’d bet on you getting a better

result. An image is worth a thousand words.

Give timely feedback

How useful do you think it is to say to a particular team member who has a bad

temper, in an end of project lessons learned session: “Your bad temper caused

the team to under perform because they always thought you were mad at

them”? If you want to correct and reinforce things using feedback you have to do

it shortly after the events. If you let a couple of days pass by it just might be too

late because the memories are not fresh anymore and people tend to give less

importance to it and think you're just over reacting.

Decide on an action plan

And all this, if done right, will end up on corrective actions you can take (when

speaking about things to do better) and things you need to do to keep on

repeating the actions you want (positive feedback again).

I need to develop I bit more on this last one. And for that suppose your basketball

team scores a lot on counter attack plays. It easily comes to mind 2 actions you

can take to enforce they keep counter attacking: you can have a couple of fast

players running to the opponent’s field every time your team gains possession of

the ball and you can make sure every player passes the ball instead of dribbling

and keeping the ball to the themselves. This is the kind of enforcement you want

to make. Good performance doesn't just happens, you have to build up the

chances for it to happen.

And again, if you make a habit out of this, you will have increasingly less things to

correct (because it has been taken care of in the past) and more things to

reinforce (because they’re performing better and better).

But you need to have a clear path on your head to take you from what the

problem is (or the good thing) to a way to correct it and prevent it (or reinforce

it). If you team doesn’t see a relation between the two you’re just losing time, so

make sure they do.

Show progress

Start the next feedback with the previous one. That’s the best way I know to

show progress (or the lack of it). And if you show progress you show your

purpose on using feedback: again, to increase your team performance.

This is also a highly motivational factor. Bill Parcells describes the motivational

process (using feedback) splendidly on a Harvard Business Review article "The

Tough Work of Turning Around a Team".

Conclusion

This is my own perspective on feedback and how I use it. Please do:

Set the scenery for feedback

Remember the one issue rule

Focus on facts and analysis

Give positive feedback

Give room to reactions

Use concrete examples

Give timely feedback

Decide on an action plan

Show progress

http://en.wikipedia.org/wiki/Bill_Parcells

http://hbr.org/2000/11/the-tough-work-of-turning-around-a-team/ar/1

http://hbr.org/2000/11/the-tough-work-of-turning-around-a-team/ar/1


But others do it somehow differently - which is in fact a good thing. You can

check Forbes 5 step feedback model here, for instance. But there are many more

available... the important thing is that you fell comfortable doing it, in a way that

feels natural to you, so that you understand what you’re doing and why you’re

doing - to increase your team performance. If you do it like you’re acting or

following a script of some kind I’m pretty sure you’ll get burned somewhere

along the line.

But if you do it naturally and your way, you’ll get an increasingly better team on

your side. Just like a dream...

Images from http://idiotcoach.blogspot.com

http://www.forbes.com/sites/prettyyoungprofessional/2011/05/16/how-to-give-feedback-that-works/


Copycats, that's what we all are

This article is about the complex relationships and behaviors within teams. As it

turns out, most of us are copycats. And that should change the way you look at

your team and you’ll find some suggestions on how to do it in this article.

But first, watch the “Face the Rear” video where everyone is facing the rear of an

elevator. Go on and watch it first, then keep on reading.

Setting the context This video was done to demonstrate the power of conformity within groups and

was based on the Asch experiments, a psychology study done back in the 50’s.

Now, what do you think? How does this relate to Project Management? First of

all, this is an evidence about groups and almost every project involve groups - so

it relates to Project Management. But project teams are much more complex

then groups of people you share an elevator with. And much more intimate, as

people in project teams are sure to share some tough moments.

The point is, if you know how people tend to follow others in the same group,

you can take advantage of it - both by preventing unwanted behaviors and

reinforcing the ones that benefit the project team.

1. You have a tendency to do like others do

in your organization But lets start with you, the project manager. Have you noticed that you

(probably) have a tendency to do like others do in your organization? By itself,

this is just a fact you can observe - it’s not good or bad as it depends on what you

imitate and the context you’re in. But just by acknowledging that you may be

imitating others is beneficial as it gives you more control. Because you

acknowledge it, it allows you to decide if you want to act like that or not.

Suppose that usually people in your organization don’t respect the starting time

of meetings. Knowing that you have a tendency to do like others do, you know

you’ll have a tendency to get late to meetings, right? But if you know that, you

can make a choice: will you get late to your next meeting or not? Maybe,

reasonably, you decide to get late because it’s an internal meeting of some sort -

and everyone else will be late anyway. Or you decide to leave the office earlier

than usual because it’s a meeting with a new customer you don’t know well yet

and because of that you don’t want to get there late. But you can now decide

what to do.

2. Your team members have a tendency to

do like other team members do You can use your team members tendency to act like the other team members to

your advantage (and also your teams and your projects advantage). Here are

some of the things you should do.

http://www.youtube.com/watch?v=NJEpazcAL9k

http://en.wikipedia.org/wiki/Asch_Experiments

http://www.youtube.com/watch?v=NJEpazcAL9k


First, this is one more reason for you to deal with unwanted behaviors as soon as

you spot them - because if you don’t this unwanted behavior will probably

spread and become a usual thing within your team.

Second, make it very explicit to the team that you appreciate the behaviors you

want every time you notice them.

And third, remember you are part of the project team and your actions are

always under a spotlight. Pay close attention to what you do, what you say and

how you say it. You should be the first one to set the example and every time

you can say to someone: “Hey, instead of doing that that way, why don’t you try

to do it like I do?” you’re on a good track. If you can’t say it that’s because you’re

not setting the example yourself - and you’re demanding of your team things you

can’t do yourself. And that doesn't sound reasonable, does it?

3. You are expected to act like other project

managers in the organization Because of this, you should know how other project managers deal with the

situations. This allows you to add a necessary explanation whenever you want to

deal with something differently. If you don’t do this, others may find you kind of

weird (because you don't act like others do) and because of that they may not

see the merit on your side for dealing with it the way you are dealing. But if you

say something like “I know you usually deal with this this way. But in this

particular case I think it’s worth doing it the other way around. I have even done

it in the past successfully” people won’t find you weird anymore. Instead they’ll

pay attention to your reasoning and focus the discussion there, either agreeing

or disagreeing with you.

With this I don’t mean that you should follow the pack but be aware when you

don’t instead - because that will take you some extra work.

4. You expect your team members to do like

other team members do Remember you (probably) expect your current team to behave the same way

your last 5 teams did. Again, the first step is to acknowledge it. And when

someone is doing something different than you expected don’t say “Hey, that’s

not the way we do things around here”. Think first about the pros and cons of

the actions in question. And in doubt, ask “Why are you doing that? Why that

way?” until you have no more doubts. And then decide if that works better for

your team and your project or not.

Imagine you propose to your team to leave on Fridays at 6 PM sharp and, say, go

bowling. Now imagine that they all exchange strange looks when you do it. Your

past project teams where all happy about leaving the office on time for a change,

why not this team? You may jump into the conclusion that they are in need of

some team building activities as they’re not interested in having some fun

together - probably they don’t really care for one another. Or it could be they all

have kids to go to and would rather do that then go bowling...

Conclusion

When in Rome, do as the Romans do. Or not. But either way please acknowledge

it. And whatever you do, please don’t jump into conclusions and use this

knowledge that most people are copycats, you included. It’s not our fault, it’s our

nature.


Beginners Guide To Project Management

Part 9, Getting a Project Team

You’ll hear this on several different subjects, but one of the most important

things that you have to manage in your project is your project team. (This is no

light statement, just consider Peter Drucker’s quote published here over a year

ago.) But this is so in any project, even in a construction project where you

probably won’t remember who actually built what - even if it was your own

house. And this why soft skills play such a key role in Project Management. So

the question is: what do you do with your team? How do you start one? How do

you keep them productive? How do you know what they’re doing? How do you

keep them happy?

Previously on the “Beginners Guide to

Project Management”

Introduction



Initiating




Planning


Part 7 - The Work Breakdown Structure

Part 8 - The Gantt Chart

The starting point Let’s start from the beginning. You have a Gantt Chart for your project already.

Look at it now and if you haven’t done it already think about the skills required

for each task there. Do you need a web designer? And a carpenter? Or maybe a

database architect? List all the skills necessary. In case you have some clear

requirement that forces you to it, add the number of people you need for the skill

(for example, you may know for a fact at this time that the project will take place

in 2 different geographic locations and you may need a carpenter in each

location). But in general, just focus on the skills.

Where to get the team There’s a wide variety of possible scenarios that you can come across. You can

have some people assigned to your project for some reason or another. Or you

may choose from people available in your organization. Or you may need to

http://www.ah-ha-moments.net/2010/06/peter-drucker-on-time.html









http://4.bp.blogspot.com/-sw0BAwzzY5c/TRHjY_dehvI/AAAAAAAAAVg/nULcBA5hVME/s1600/joined-hands.jpg


recruit new people to your organization that will work in your project. Or you can

outsource some of the work. Or all the work. And all of this can be done with a

team brought together into just one place. Or you can use virtual teams

(meaning that team members are scattered over different geographical

locations).

The process is usually very straight forward: if you have the necessary skills

inside your organization, you’ll use them as long as people don’t have too much

in their hands. If not, you need to hire outside the organization. But you can run

into all sorts of problems here, in particular if you have a weak matrix

organization. In this case you have to negotiate with the functional managers to

get their best resources and offer him back... well... very little really. Maybe some

recognition at the end of the project.

One other thing that may come out of this effort is a more concrete idea about

how many people for each needed skill will you have in your team. Suppose there

are no carpenters in your organization and you’ll have to get one. You’ll probably

have just one carpenter in your team because of the costs associated (or not, if a

carpenter is needed in 2 different locations like the previous example).

Getting a team is also a progressive work. You’ll have to balance it with costs and

time and all the other dimensions that play a role in project planning (and you

may have noticed that I haven’t discussed costs with you; yet). You’ll be sure to

revisit this article and keep it fine tuned all the project long. You know that

people get sick occasionally. What if someone you need in you project some time

in the future gets sick when you need her/him? Or leaves the organization? Right,

you’ll revisit this article.

Responsibility Assignment Matrix After knowing who will be part of the project team, you can and should explicit

the roles and make them public within the project team. I find a Responsibility

Assignment Matrix (RAM) very useful for these, including to easily integrate team

members that arrive late in the project as it allows them to check who’s who

easily.

I don’t think you’ll find the RAM I use the most very useful (I use it because of the

Portuguese culture). If this is the first time you’re reading about RAM’s, you

should probably be safe using a RACI one, where R stands for responsible, A for

accountable, C for Consult and I for Inform. The idea is to list to some extend the

activities in the project in a column like in the chart below. The detail will vary

from project to project, but I either go for the WBS structure or the activities

themselves (I don’t think I ever used another level of detail). Then for each team

member clearly identified you put the role (responsible, accountable, consult or

inform) to each activity or WBS entry.

Now you may think this is all too obvious and maybe a waste of time. But you’ll

be surprised how many people forget about obvious stuff when working in a

project and this is the kind of thing I don’t want team members to forget: their

role.

Update Gantt Chart

We will come back to the Gantt Chart again, but it may be a good time to update

the Gantt Chart not only with the names of the team members but also adjusting

http://1.bp.blogspot.com/-D-VKbGUZh6c/TqHY1kjCOrI/AAAAAAAAAh4/79Qu_7SyKhg/s1600/raci+ram.JPG


tasks durations. The durations may be adjusted for several reasons: you were

thinking of an experienced carpenter but all you could find was someone with

much less experience or may have now 4 carpenters planned instead of 2 and so

the durations of the tasks should be less. In the end, this will give you the staffing

needs for your project.

As you may have noticed we still didn’t cover the budget for the project, so if you

feel the budget might be a problem, please skip this step and get some

confidence on the budget’s approval first.

What about all the rest?

Remember the questions at the beginning? How do you keep your team

productive, how do you know what they’re doing and how do you keep them

happy? This is the topic of many Project Management books so don’t expected to

know it all from a couple of paragraphs about it on this article, OK? But even on

small projects with small teams there things to keep in mind.

Motivation

Maybe unexpectedly for you, money isn’t a key motivator for non-manual jobs.

For these, the 2 main, general motivators are the sense of belonging and the

feeling of progress. Probably the easiest way to have a team motivated is making

sure progress is public at the team level. That’s why a burn down chart in a board

is such a key element in Scrum: everyone is looking at the team’s progress,

updated daily, and visible to all in the team.

Expectations

You will have to manage every stakeholders’ expectations, in particular those of

your team members: are they construction workers’ that are building just

another building or are they PhDs working on a break through vaccine? Can you

help them grow as professionals? What do they expect to be doing next year?

The scenarios are endless but one thing is for sure: you have to manage their

expectations.

And these should be planned. I’m sorry I can’t give you a tool to help you carrying

out this planning but if you have motivations and expectations on your mind all

the time you’ll know how to do it.

Conclusion

Without a team you have no project. So pay close attention to what you do with

it. Get the team, either inside your organization or not, and play fair with them all

the time. Start with a Responsibility Assignment Matrix to make sure everything

related to their role is crystal clear. And always keep motivations and

expectations in your mind. And please remember your team looks to you, you're

their leader.


How to run meetings

Seth Godin said recently in his blog that the reason why he is so productive is

because he doesn’t attend any meetings. I’m pretty sure this is an exaggeration

but he does have a point: some meetings should never be in the first place and

the ones that should are sometimes conducted in a very inefficient way. That’s

why I’m sharing my views on meetings and also some tools and tips to deal with

them, including a ready to use meeting template.

This is relevant for Project Managers

Because they all attend lots of meetings. And because they need to be as

efficient as they possibly can (can you imagine someone wanting to hire an

inefficient Project Manager?). The statistics vary from source, but I have no doubt

that Project Managers spend most of their time communicating and that most of

this time is spent communicating in meetings. And so spending less time in

meetings, preparing them and follow up on them seems like a great idea to me.

How efficient do you think such a meeting as the one in the picture above is?

How many time were you in a meeting thinking "This is going nowhere, I should

be doing something else"?

A meeting minute template

Some tools may help you to get a grip on those meetings. Let's start with the

most complete and complex meeting template I use. Just consider it and adapt it

to your particular needs (and maybe share it here). Keep in mind that you have

every benefit to use just one template to all your meetings (for example, no need

to waste time deciding which template is the best for this meeting, or to try to

remember which template you used so you can search accordingly). So here we

go:

Meeting topic

Where, date and time

Attendees

1. Agenda

1. Topic

...

N. Topic

2. Decisions

1. Decision

...

N. Decision

3. Tasks (Task, Responsible, Done by)

1. Task

...

N. Task

4. Comments

1. Comment

http://sethgodin.typepad.com/

http://1.bp.blogspot.com/-bEkIzQtG2IQ/TqrM5FhXo7I/AAAAAAAAAiY/7dcV-A9DNJg/s1600/Meeting.jpg


...

N. Comment

The header contains:

The meeting topic that should be as straight to the point as you can (something like “Project X, Status Meeting” or “Guidelines for the 2012 budget”).

Where and when the meeting took place. You should take care in writing places and dates in the same format for ease of search sake.

The name of all the attendees. The previous note is also valid and I have some others tips that may be of use to you:

1. The names of people that work regularly with me are shortened to their initials (for instance, Luis Seabra Coelho becomes LSC),

2. For people I meet from other companies I also add their company name (it’s easier for me to remember them this way) and

3. If someone was supposed to be on the meeting but missed it for some reason I add an”X” after the name (if I missed a meeting I’d be in the attendee list as “LSC X”)

The Agenda is the Agenda, right? The topics that are going to be covered in the

meeting should be listed here with the estimated duration.

Decisions are not stuff for people to do, those go into the tasks. Decisions are

more broad, like “Outsource this work”, for instance. In this case case there are

multiple tasks that must take place in order carry out the decision.

Tasks are what is assigned to someone to do like “Susan will issue an RFP for

something to suppliers A to D by the end of the month”.

And Comments are everything else. These are usually personal, but I find myself

adding comments on project status meetings public minutes whenever there’s

something worth mentioning that doesn’t fit any of the previous sections. Some

details on Susan’s task could go here, for instance, including a 60 day payment or

a maintenance add-on of 20 hours per month or whatever.

One thing I've tried for some time was to keep the decisions, tasks and

comments under each topic of the agenda but in some cases this doesn't work.

There could be a decision or a comment that doesn't fit none of the topics as it

may apply to more than just one item on the Agenda.

10 Tips for running meetings

1. Meetings involve people. Often, what people show with their attitude or facial expression is more important than what they actually say. Forget about this template and tips if you must but don’t forget this one: meetings involve people.

2. Take your notes live. Some people simply can't do this, do it just after the meeting if this is your case. Notes taken 2 days after are of no use to anyone.

3. Clean up after the meeting. After the meeting, read your notes, clean the text, check the spelling and rephrase them if necessary.

4. Keep it focused. If you find something in your notes that you’re not sure if it's relevant or not, delete it. Yes, delete it. If you’re not sure now if you’ll ever need it, the odds are you will never need it.

5. Add a topic to follow up previous pending tasks. When you have regular meetings, such as project status meetings, you can add in the Agenda a topic for checking the status of the previously assigned tasks. This way you keep the template simple and keep the focus just on the tasks that are pending.

6. Set the example. Be on time and start the meeting as soon as you can, whatever that is in your particular case. It would be perfect to start at the scheduled time but this won't happen at least in my part of the


world. If you’re still alone at the time the meeting was scheduled to star, start the meeting as soon as the first person arrives. This will give a strong sign to whoever arrives late.

7. Give people time. Schedule the meeting some time in advance and send the Agenda when you do it. Also send any documentation necessary to the meeting if you can. If you can’t, like most project status meetings, send the documents as soon as you have them - unless you have a good reason not to do it.

8. Account for what's not in the Agenda. Reserve time to everything happening in the meeting. If you need some time to chitchat prior to take on the Agenda topics, include it in the first topic of the Agenda – but don’t make it explicit there!

9. Timers. If you can, try to use a timer during the meeting to keep each topic in the Agenda under control. I bet this works in some cultures but not on mine.

10. Odd times. If you can, try setting the meeting to start at odd times like 9:13 AM. I’m pretty sure I’d be locked up in a psychiatric Hospital really fast if I tried this one at my office. But in some cultures this could be seen as a sign that the meeting is to start on time.

Conclusion

Meetings are all about people communicating so running them is more like an

art then a science. But there are some things you can at least try to make them

work in a more efficient fashion. And there also tools, like the template I shared,

that can help you to keep track of what's going on, what are the tasks still

pending on a particular topic and so on. You can be more efficient and because of

that you can save some of your precious time to do other things.

And you are most welcome to share your experience here. I think I'm to used to

this template to get it any better, maybe you can help.

Pictures taken from http://en.wikipedia.org/


International Project Management Day and non-Project

Managers

The International Project Management Day (IPM Day) takes place every first

Thursday of November and this year it took place yesterday, November 3. As far

as I could find out on the International Project Management Day website, the

responsible for this is Frank Saladis.

If you ask me, this is a great idea. Celebrating ones profession has a very positive

connotation associated with it. It ranges from plain having fun to the sense of

belonging (one of the top motivators) as you can say “Hey, I’m a Project

Manager, it’s my day!”. Thank you Frank!

Initiatives

There were several initiatives to celebrate yesterday's IPM Day, but I’m gonna

focus the attention on the International Institute for Learning’s (IIL) “Power of the

Professional” for the following reasons:

A top selection of speakers

A variety of topics ranging from emotional intelligence to Sharepoint

12 PDUs (useful for keeping your Project Management Professional credential, irrelevant otherwise)

And it was all for free!

What more could you want? It was really great and I do hope IIL repeats again

next IPM Day. I planned to assist all the presentations but something came up at

work (sounds familiar?) and I couldn't. Even so I was abble to assist to 6 video

presentations and it was time well spent, even the Sharepoint presentation was

useful as it showed a way to deploy software almost for free to assist you with

the planning, collaboration and communication within Project Management - if

you're now working in Portugal like I do (or Greece, or maybe even Ireland or

Spain) you would appreciate this a lot more, I’m sure. The presentations I was

able to assist were:

"The need for metrics: Measuring the Ongoing Value of a Project" by Dr. Harold Kerzner

"Looking Ahead in Turbulent Times" by Mark Langley

"The Value-Driven Project Manager" by Frank Saladis

"Behind the Frontlines: Building Emotional Intelligence in Kabul" by Christa Kirby

"Leadership - Latest Research on How Best to Influence people" by Lynne Hambleton

"Using Sharepoint for Project and Portfolio Management" by Eamonn McGuinness

All these presentations were relevant, some were fantastic from the

communication point of view and it was time well spent. I downloaded the slides

for all presentations anyway so I could check them later. It's not the same thing

as watching the video presentations but hopefully IIL will share them also.

http://www.internationalpmday.org/


http://www.iil.com/


http://www.iil.com/


How to get a better IPM Day next year

This IPM Day initiative is great but as it is directed to Project Managers it also

separates us from those who are not into the profession. I think this is something

that is really missing in the profession and it would be great to take this day to

show what we do to others. I mean, how do you recognize a Project Manager?

Because of one’s title on a business card? It would be easier if Project Managers

had some uniform like a Fireman, a Doctor or a Policeman does - but Project

Managers don’t have a uniform. And even worse, in certain industries like

Construction (where Project Management plays a critical role) it’s pretty difficult

to explain why they need Project Management (I really could never understand

this one!). This is my experience in Portugal, I don’t really know how much you

can extrapolate from it as I do meet a lot of people working in Construction on

the PMI Congresses - go figure it. But at least in my part of the world, people in

Construction take everything they do, Project Management included, as a single

package and somehow refuse to see what others are doing with the discipline, on

its own, in other industries.

Now some people are working very hard to spread the Project Management

discipline to everyone - especially those that don’t work in the field. One example

is the Project Management Institute Educational Foundation (PMIEF) who have

made available some resources for non-project managers, including a kind of

light weight Project Management Book of Knowledge (PMBOK) for kids on

Elementary School. Wouldn’t it be great if they were associated to next year’s

IPM Day? This is my wish for next year’s IPM Day: that we can have some events

directed to people not into Project Management.

Bottom line is we still have a long way to go. It looks to me, now, that when we

recognize a Project Manager as easily as Fireman, we’ve done the harder part of

the path. But I’m sure we’ll have other challenges then.

http://www.pmi.org/pmief/

http://www.pmi.org/pmief/


Are you a Professional Volunteer? You're needed in

Project Management!

If you associated “volunteer” to doing good deeds such as doctors that go to

remote places after some natural disaster, you’re on the right path. And if that's

the case, you must be wondering:

1. how can a volunteer be a professional (or a professional be a volunteer) and

2. what’s that to do with Project Management?

Well, this is what this article tries to answer.

How can a volunteer by professional? I like dictionary definitions as they’re usually very dry but straight to the point.

And this case of “professional” and “volunteer” is no exception. I was expecting

to go through a few dictionaries until I got what I needed to include in this article

but there was no need: the online dictionary I use the most had exactly what I

needed to make my point. So please check with me the following definitions

before we continue.

Professional, in the dictionary, is:

of, relating to, or characteristic of a profession

engaged in one of the learned professions

characterized by or conforming to the technical or ethical standards of a profession

exhibiting a courteous, conscientious, and generally businesslike manner in the workplace

participating for gain or livelihood in an activity or field of endeavor often engaged in by amateurs - a golfer

having a particular profession as a permanent career - a professional soldier

engaged in by persons receiving financial return - professional football

And the voluntary, int the dictionary, is:

proceeding from the will or from one's own choice or consent

unconstrained by interference : self-determining

done by design or intention : intentional - voluntary manslaughter

of, relating to, subject to, or regulated by the will - voluntary behavior

having power of free choice

provided or supported by voluntary action - voluntary organization

acting or done of one's own free will without valuable consideration or legal obligation

You’ll reach the conclusion that there’s nothing contradictory in them although

http://www.merriam-webster.com/dictionary/professional

http://www.merriam-webster.com/dictionary/voluntary

http://4.bp.blogspot.com/-kSpZcV2Sc5I/Tr1KVpFUB1I/AAAAAAAAAjg/_AGWYc-gXb0/s1600/doctors.jpg


there should be some indication in the volunteer definition for no monetary

compensation. Are you surprised?

For the purpose of this article, you can take these definitions, remove the

"monetary compensation" from the professional definition and add "no

monetary compensation" to the volunteer one. And so we can define a

professional volunteer as:

Intentionally performing a set of skills by one’s free choice with an attitude that

exhibits technical competency, ethical standards and empathy towards others.

I am a professional volunteer as much as time allows. I reported some time ago

my first project in this area on the article “Lessons Learned from My First Doing

the Right Thing Project”, I am also the Assistant Director for Podcasts on the

Project Management Institute Information Systems Community of Practice and

I’m about to redo a website for a Portuguese non-profit organization. This blog is

also the result of the work of professional volunteers (mine and others). And all

this work is done with no monetary compensation.

And why shouldn’t I do it? Can you think of a single reason why I shouldn’t take

an action to help others that costs me almost anything? This is basically why I do

it but each person does it for a different compensation, but there’s always some

compensation - you just have to find out what’s yours.

What’s that to do with Project

Management?

In a word: motivation. If you have a team where each member (and you

included) “intentionally performs a set of skills by his/her free choice with an

attitude that exhibits technical competency, ethical standards and empathy

towards others” you live in a perfect world! But if you have that you have a highly

competent, mature, motivated and efficient team - and all you have to do to get

it is to find out what tickles each person and give him/her that. Straight simple,

right? Well, it’s simple alright. The problem is that simple doesn’t mean easy...

intentionally...

But let’s take a closer look at this, starting with the intention. At the very least

this implies that each team member knows what his/her mission and vision are

(both in a business like sense). They have to be familiar with the larger picture

where the projects sits - and if sometimes it’s difficult for the project manager to

know that it’s even harder to have that message reach and be understood by

each team member. If you don't know about the project context you will never

have the chance to choose a particular action that fulfills a larger purpose.

...performs a set of skills...

Each person has a set of skills where he/she is proficient at. Do you know your

team’s set of skills? Starting from the basics, you probably asked for a Web

Designer and a Database Administrator (or whatever) when the project started.

Do you know what skills exactly did you get? It could be that your Web Designer

is a hardware geek and you Database Administrator is also into Business

Intelligence. And it could be that those other skills could come in handy. Even

harder to spot and analyze than these types of skills, is to balance the funny guy

with the creative one that comes with this simple solution to that awkward

problem and the guy that needs to provide everyone with whatever their needs

are. You don’t put these on your Resource Plan, do you?

http://www.ah-ha-moments.net/2010/07/lessons-learned-from-my-first-doing.html

http://www.ah-ha-moments.net/2010/07/lessons-learned-from-my-first-doing.html

http://is.vc.pmi.org/


...by his/her free choice...

Having someone assigned to your team is a completely different scenario than

having that someone knocking at your door asking if they can be on your team,

isn’t it? Now, if someone wants to be in your team he/she is highly motivated for

sure, so the only thing left for you to do is (i) make others want to be in your

team and (ii) keep them highly motivated after they're in. Pretty simple, hein?

But not easy.

...with an attitude that exhibits technical

competency...

Project management is a lot about geting things done, right? So you better get

people who know about what you want to get done. It's hard to imagine how

you're going to build a bridge without people who have skills on building

bridges...

...ethical standards...

I'm sorry to insist on this but I do find it mandatory to at least mention ethics and

morals. But I don't mean it in the sense of politically correct, I mean it more in

the sense of people feeling like they're doing the right thing. And this feeling can

be a really powerful motivator.

...and empathy towards others

Empathy is about understanding others. You don't have to agree with them, but

if you can understand them good enough to feel their pain - well, that's

empathy. And empathy is a basic step towards a performing team. Basically it

works like this: if you are to explain to someone why you strongly disagree with

them, they're more likely to listen to you if you have previously listened to them.

Conclusion

This article is not a how to guide, it’s not very practical but it sets a context for

your project teams that gives you a useful perspective on things. And sometimes

that's all you need to make things move forward.

But better yet is the attitude. I find this a very healthy posture towards things and

Project Management in particular. And having this present in your mind may

hopefully get you better and better teams that in turn may make you a better

Project Manager.

Image: photostock / FreeDigitalPhotos.net

http://www.freedigitalphotos.net/images/view_photog.php?photogid=2125



Part 10, The Project Budget

Knowing (or predicting) how much the project will cost is critical from getting

approval for the project till the very end of the project where you can extract

some performance indication of how well the project manager did. In between,

the project costs form a baseline, much like the project's schedule, that allows

the project manager to have some control over the project: to correct course

when needed and to evaluate the impact of changes as they occur. Moreover, it

allows the project manager to update the initial estimates as the project evolves

so the project manager can tell at any point in time what is now the estimate for

the total project cost.



Introduction



Initiating




Planning




Part 9 - Getting a Project Team

Context

But starting from the beginning, what is a project budget? A project budget is a

schedule with all the planned costs of the project - human resources, contracts

and materials. This means that you associate a cost, a date (or a period like a

month) and either an activity, a contract or a material. And it serves as an

estimate of cash needs along the project life. In practice, you can use your

schedule and add the cost information to each activity listed there. Although

some types of costs are pretty obvious to put in a schedule, others are not:

where do you put on the schedule the rent you're paying for the office where

your team is working? What about the equipment you'll have to buy, like a










http://3.bp.blogspot.com/-vatZz8RtECQ/Tsae2PJb21I/AAAAAAAAAkA/WmlyoWlu7Fw/s1600/purse.jpg


printer, for instance?

Isn't this a bit of an exaggeration? I mean, when you need something done in

your home (like new windows) you just call a contractor, tell him what you want

and he looks around, counts the windows, checks with you what type of windows

you want and then he says how much it will cost you, right? Sure it's like that in

simple cases, but even so in this case the contractor had to go through the basics

of the process of building a budget - and this is the purpose of this article: to

show you how to get a project budget.

(i) Get the schedule I don't think there's a significant chance of doing a budget without using some

software (like the contractor did in the previous example) so I'll assume you're

using some kind of Project Management software where your schedule is already

put in.

To build a budget you'll also need to have present in your mind the whys and

whats. This is key to have you focused on the budget that best serves your

project. Remember the Sidney Opera House project? If you don't, you'll probably

be surprised to learn that the project itself was considered a completely failure

then - there was a huge cost overrun and some of the reasons for that where a

mismatch as to purpose (the whys) between the architect that designed it and

the project sponsor. You can check part of that story here.

(ii) Estimate activity costs This is the basis of building the budget, as all of the budget is support upon the

estimates you come up with for each activity on your schedule. Now the question

is: how do you estimate the cost of a given activity (and you'll have to do it for

each activity on your schedule)? Depending on you project, you can do it

combining some of the following (this is not an exhaustive list but just the most

common I found in my own experience):

Your experience: or in a more general way, what the Project Management Book of Knowledge calls "Expert judgment". Imagine you are the contractor in the previous example. Your experience from previous similar projects (where you had to change windows in a house) tells you that each window costs a certain amount of money and you can use that figure.

The team's experience: if at this point you have a team assigned you could have used the team's opinion to build the schedule and so use it again now to compute how much that would cost having so many people doing it. This is the approach used in Agile and has the visible benefit of commitment of the people who are actually doing it.

Parametric estimation: this is commonly used in industries such as construction where it's expected to have data on average values like the cost of painting a square meter (or foot) of external walls. The idea is, having these average unit costs, compute the total multiplying it by the total area.

One good thing to record alongside with the estimates is the assumptions

associated to them and possibly also the basis (your experience, your team's

experience or parametric) and the range (for instance, between 1.000 and 1.100

€ - or USD or whatever the currency used). Now, when you have an estimate all

you have to do is to add it to your schedule. Once you do it for each activity, you

can have the total cost of the project, right?

(iii) Add "hidden" costs Not quite. What about the costs that are not related to manpower? You'll have

to buy paints and brushes (or whatever you use to paint a building) if that's what

you're going to do. You may have to rent some equipment that allows access to

http://en.wikipedia.org/wiki/Sydney_Opera_House


the exterior walls of the building. And even worse are the costs that are not even

related to any activity in particular; such is the case where you have to rent an

office for your project team. All of these have to be incorporated into your

schedule somehow if you choose this approach - and I do think this is the best

way to do it in most projects (the exceptions would be big projects (in duration

and in cost) and in such case this guide isn't for you to apply, maybe just take a

few ideas from).

Most Project Management software available has a way to specify variable and

fixed costs of activities (variable or fixed as to the duration of the activity). So

variable costs would be the ones related to manpower or renting a machine - the

longer the activity lasts the more you pay. The fixed costs would be related to

those things that you have to buy in order to do what you have to do: in the case

of the constructor and the windows, each window would be a fixed cost as you

would have to buy them and the cost will be the same if you exchange each

window in an hour, a day or a week.

In the particular case where you have such costs as renting an office for your

project team or any other kind of contract, the down side of putting them into

the schedule is that you'll end up with a distorted schedule, that is, you'll end up

with a schedule where there are activities that are not activities - like the monthly

rent of the office. Oh yes, I didn't say it yest but you can change the schedule in

this phase! The benefits from having one single document also with the

information regarding costs largely compensates this in most cases. Plus, you can

include these costs in an explicit way in your schedule that shows to anyone that

these are costs not directly related to work.You can even change the WBS at his

point to fine tune it by adding a branch titled "Fixed project costs" or whatever

suits your particular case the best.

(iv) Other things that may play a part in the

budget

Although there is a lot more to say about budgets (there are plenty of books

about it and I'm synthesizing all that in this short article) there a couple of things

that I think you should have in mind because they can have a huge impact on it:

risks and context.

The risk associated with replacing your home's windows compared to the risk

associated to a break through project (like the Sidney Opera House) is really

small. You should somehow incorporate the risk into the budget. One bad idea is

to increase your estimates (in duration and in cost) for each activity, but it's a bad

idea basically because you loose any useful metrics in the process.The most

common way to deal with this is either to (i) record the range of your estimates

(if all goes as expected it will cost 1.000 € but if a certain risk occurs it could cost

2.500 €) or (ii) build a funds reserve. Both have benefits and cons, but I like the

funds reserve better just because it's more transparent.

The other thing that can have a huge impact on the budget is what I called

(lacking a better word) context. Context is the culture around your project (the

culture of your project team, your key stakeholders and the organizations

involved), the economic context (is everyone counting their pennies, for

instance?) and the political environment (in the country and in the organizations

involved). Just imagine you just started a governmental project last month in

Italy. The government just changed, where does that leave your project?

Conclusion

It's a pretty good idea to start aiming at the end as far as budgets go. This article

covered the very basics of project budgeting but I can tell you that, for example,

if you plan to use Earned Value Management for project monitoring this article

won't help you more than setting the very basics of it. But budgeting is always

necessary when it comes to projects: from the very beginning when your sponsor



needs to know how much the project will cost till the very end where, want it or

not, your performance will be evaluated also by comparing how much the project

was supposed to cost and how much was actually spent on it.

And even the contractor that goes to your home, looks around and shoots a price

for replacing all your windows, does it pretty sharply.

Images from http://www.europarl.europa.eu


Stress free Project Managers...

...Or about Hammers and Screws

Projects can be very stressful but in fact there are only 3 dimensions to it:

deliverables, people and organizations. So how difficult can it be to manage

projects? Where does the stress come from? After all, these 3 dimensions are

what we're all used to no matter where you're from, right? That is exactly how

we look at things and how we are aware of the space around us. Now in some

cases, we feel stress just because we don't have a mental frame where to fit

what's happening around us. So, by having this larger picture in mind we can fit

things in their dimensions and, if the stress we were feeling was caused by it... no

more stress! What a perfect world, isn't it?

Starting with stress

I remember one time I went shopping alone with my kids, they must have been 2

and 3 years old at the time. At one point, when the shopping cart was already

quite full, one of the kids has to go to the bathroom. Of course the other one

immediately felt the urge to go too. Believe it or not, I panicked for a few

seconds: should I abandon the shopping cart and go with them to the bathroom

and start shopping all over again afterwards? Should I leave one kid inside the

cart, go with the other, come back, go again with the one that was left in the cart

and leave the other one in the cart? Or would they let me leave with the

shopping cart without paying, go to the bathroom with them and continue

shopping afterwards?

I believe the reason for the panic was just because it was the first time this was

happening and I had no mental frame to put it into context: a supermarcket was

just a place where you took a shopping cart, put the stuff you need in it and pay

for it on your way out. I never gave a second though about the bathrooms in

there, the security or even the registers. After re-framing the situation in my

mind, it was plain to see that all I had to do was to leave the shopping cart with

the security at the entrance, go with the kids to the bathroom and then continue

my shopping. But during those few seconds I just didn't see a way out.

The same goes to Project Management. Once you have a broader view of things

you get these nice little boxes in your mind where you can put stuff in and feel

comfortable on doing so because you know there are appropriate actions you

can take on them. And the first nice little (or not) Project Management box is...

The deliverables

The focus of most work developed on Project Management is on getting things

done and deliverables - the OTOBOS (On Time, On Budget and On Scope)



http://2.bp.blogspot.com/-46MUrYegtwo/Ts_fJblplwI/AAAAAAAAAkY/7CygaXPQvJQ/s1600/hammer-and-screw.jpg


approach. If you look at the Project Management Book of Knowledge (PMBOK),

almost everything there deals with this. It's all about the processes, and the tools

and the techniques available to get things done.

The people

Most problems I have experienced in Project Management were tracked back to

people. Problems like conflict of interests and different priorities have nothing

to do with what has to be done to deliver the project's results but it has a direct

impact on the project. You can know all about Earned Value Management and

Gantt Charts that none of that will help you with people. What will help you

instead are soft skills such as negotiation, leadership, and communication. These

are the tools that can help you to deal with people.

This view is fairly recent but is growing in importance up to the point where there

are people who say that soft skills is what they want from a Project Manager, all

the rest they can learn on the job. You can either agree or not with this

statement (I don't subscribe it myself), but the reason for this is the following: if

you have a leadership profile similar to a General's you will never be an

outstanding Sargent; but if you already have a leadership profile similar to a

Sargent you can develop your leadership skills to become an outstanding

Sargent. So there's a point to such a bold statement and you can check the article

"Developing Leadership Skills" if you want to learn more on this.

The organizations

This is where strategies and politics are. If nothing else, keep this in mind: your

project's results are of no use to anyone if they don't build on the organization's

strategy. There's no purpose on developing a new mobile phone if your company

is dropping that line of business, is there? So please, please keep in mind that

your project exists to help achieve some business need and that your project

probably works together with other initiatives in the organization (projects and

operations) in order to achieve it.

Business Analysis is probably the best tool to work on this side of the triangle -

but this is my opinion just because it's the only tool I know to deal with these.

Conclusion

The practical advice I have for you is this: when you're faced with an issue, place

it under the correct perspective and use the tools provided under that same

perspective to deal with it. If you have someone in your team that systematic

arrives late at the office, showing her a Gantt Chart reminding her what she has

to do in that week is of no use. But if you provide some feedback to her and

show her that other people on the team have to wait for her to get to the office

in order to start working and that she's arrived late at least 30 minutes in the last

few of days it would at least fire the discussion in turn of a solution to the

problem.

In short, putting problems on the right perspective helps finding a way to deal

with them and thus prevent the stress of having to deal with the same issue over

and over again - no point in using a hammer in a screw, is there? On the other

hand, if you insist on using hammers with screws I bet that will be a source of

stress and frustration...

http://www.ah-ha-moments.net/2010/06/developing-leadership-skills.html

http://www.ah-ha-moments.net/2011/10/how-to-give-feedback.html


Picture from http://wherethereispeter.blogspot.com


Capturing project success

Project success is something hard to capture. One person can find a project

successful while another person finds it a failure. A project could be on time, on

budget and on scope (so it was a success) but in the end the organization didn't

use it (so it was a failure). Or maybe the final costs were hugely over budget (so it

was a failure) but 10 years after the return on investment was huge as well (so it

was a success). Or maybe although it was late (and so a failure) everyone that

uses its results is very happy about it (and so it was a success). The combinations

seem endless... So how do you capture project success?

Putting success in context

Project Management has 3 dimensions to it (please check "Stress Free Project

Managers" for some more detail on this):

Deliverables: and their cost, the time it took to deliver them, their scope and quality

People: how happy were your stakeholders with what you delivered? How happy were they with you? How motivated was your team? How well did you negotiate the resources?

Organizations: did they use the project's deliverables? Did they add business value to the organization?

These names for the dimensions may not be the best ones but they have a great

virtue: it's hard to mistaken them. That is, if you think about time, budget and

scope you are definitely on the "deliverables" dimension; and if you think about

the organization use of the project's outcome you are definitely on the

"organizations" dimension.

So you get metrics It seems that finding metrics for each of these dimensions would do the job and

allow you to have a global measure of project success. But this is now all that

linear: if you think so, then the Sydney Opera House must be considered a failure

(in short, it was delivered 10 years late and 15 times over budget but check

Wkipedia for more details) - but somehow this doesn't seem right, does it?

Sometimes, and in particular in big, lengthy or breakthrough projects, you have

to add a time dimension because what you measure when the project is just

finished is different in 2 or 5 years.

I also have to add that sometime ago, on the Beginners Guide to Project

Management, I stated that "you’re a successful Project Manager if your main

stakeholders are happy with your project and its outputs". This definition of

project success has all the 3 dimensions included:

Main stakeholders - people dimension

Project - deliverables dimension

Outputs (in the sense of something new available in the organization) - organizations dimension

http://www.ah-ha-moments.net/2011/11/stress-free-project-managers.html

http://www.ah-ha-moments.net/2011/11/stress-free-project-managers.html

http://en.wikipedia.org/wiki/Sydney_Opera_House#Completion_and_cost



http://4.bp.blogspot.com/-oUdM-PFE02w/TtkZuTIQuUI/AAAAAAAAAk4/K5is1bexBPw/s1600/success2.jpg


Bottom line is you need metrics on each of these dimensions to capture a project

success. Any other way will be either perspective dependent, too narrow or just

subjective.

There's not one recipe for project success

If you include all the metrics necessary to capture these 4 dimensions you

probably end up with so much stuff to measure that any small or medium project

will have its costs and schedule increased significantly just so you can measure

what you need. On the other hand, if you ignore the time dimension you have to

consider the Sydney Opera House a failure. This looks like a trap...

The best way out of this is to have different sets of metrics for different types of

projects. It does seem reasonable to me if you think of highly dynamic projects

such as marketing projects and very predictable ones such as construction

projects (at least in general terms). If the projects in your organization vary

mainly in size and degree of expected change, why not capture that in your

metrics? Small projects with little expected change would have a set of metrics,

small projects with many expected changes would have another set, big projects

with many expected changes would have yet another set of metrics and so on.

What do you lose? Mainly the ability to compare projects in different categories.

But then again, comparing a marketing project to a construction project will not

be all that useful. It looks to me that what you lose is largely compensated. But

then again, this is just my own experience and I'd really appreciate if you could

provide a different perspective.

What about baselines? In principle, you can only get good metrics if you use the last baseline for

comparison. If the scope changed so much from the beginning of the project to

what was actual delivered, it doesn't make much sense to compare your actual

figures at the end of the project with the ones in your initial plan. But... if you

rebaseline your project just before closing it, all your metrics will probably look

very, very good. The only way out is to allow a new baseline on any given project

only when things change so much that no one can raise the question "why a new

baseline?".

Project success in 4 steps In short, to capture success, all you have to do is:

1. Determine what types of projects are done in your organization. 2. Build simple rules to determine which projects go into which category

(budget amount, length, risk exposure, complexity,...) 3. Get metrics for the 3 (or 4) dimensions for each category of projects in

your organization. 4. Provide for whatever is needed to get these metrics (what data, in what

format, where,...)

And now you can say if a project is a success and, better yet, how much of a

success it was! It may seem easy when put this way but... why don't you try it for

real?

Pictures taken from http://mariaeves.com



Part 11, The Project Communication Plan

Project managers communicate. A lot. And the way they do it and what they say

usually has a big impact on the project end result. So this is something you should

pay particular attention from the very beginning of the project till the very end.

Also, the communication plan itself is bound to change during the project as you

get feedback from the stakeholders - it's probably the most dynamic part of the

planning.



Introduction



Initiating




Planning




Part 9 - Getting a Project Team

Part 10 - The Project Budget

How do you start?

The starting point are the stakeholders (the who part). You cross them with your

project's schedule (the how part), namely milestones, and then decide what

information is relevant for each stakeholder. Then you add the periodic

information each stakeholder needs and you're all set. In the end you can have

something like the following table:

Stakeholder Document Time frame Responsible Medium

Any Meeting

minutes Up to the day after any

meeting Project

Manager Email











http://4.bp.blogspot.com/-otINK1DVSBA/TuJKBogfYtI/AAAAAAAAAlY/FhDST_3TAxk/s1600/CommunicationPlan.jpg


Project

Manager Time register Every Friday until 3 PM Team

members Software

Sponsor Status report Every Friday until 5 PM Project

Manager Meeting

Project

Manager Change

request Anytime needed Any

stakeholder Email

A couple of things to keep in mind when you build this table:

Is the information you intend to share both enough and sufficient to that stakeholder?

Is there a way to collect the information you need to build that report? Can you get the information on time to build the report upon it?

Getting feedback Unless you already know everyone involved in the project, you will miss some of

your communication objectives. But don't worry, that's how it goes.

The first thing to do when you send or present a document is to get feedback.

Providing feedback is one thing, getting it is another. To get feedback on the

presentation you just did, if you start by saying something like "I can't believe

how good this presentation was. I managed to get the exact format and content

people needed. The proof is that there were no questions", what do you think the

other person will say? Probably not much except agreeing with you. But if you

start with something like "I expected a lot of questions after the presentation,

why do you think no one raised a question?" the odds of getting some feedback

are a lot better - in general, open questions are much better to get feedback

from someone. Maybe there were no questions just because you based your

status on Earned Value without checking first if the people that attended the

presentation knew what Earned Value Management was... ouch!

Adapt and change So the Project Communication Plan (that in its simplest form can consist in just

the previous table) is bound to change. Don't be afraid, just change it to the

better, let everyone know that it has changed and go back to collecting feedback.

Sometimes changes don't impact on the type of information being shared but on

its contents or format. The same applies: change it to the better, let its recipients

know it has changed and ask for feedback.

Elevator speeches An elevator speech is a communication done in a very short period of time, like

the time it takes you to get to your floor using an elevator (30 seconds or

something like that). This is a communication tool that you won't find in the

communication plan but it can be much more useful than anything you find

there. I always have some elevator speeches in my projects, being the main one

a status of the project. Now, depending on the person who you are with, this

status should be communicated in different forms - in fact, different elevator

speeches. If you happen to bump into the project sponsor and he naturally asks

"How is the project going" you can take the chance to say "Fine, but I could really

use your help to talk to the Financial Director. He seems really busy and I haven't

been able to reach him. Could you please let him know I really need to talk to

him?" Much better than raising these issues at status meetings, don't you think?

The thing is, you should have these speeches prepared before you need them. It

may happen you never use them as you might never bump by chance into the



necessary people, but if you do bump into them you have something relevant to

say - instead of stutter and comment on the weather or the last big football

match.

Conclusion

The Communication Plan is simple but necessary so don't neglect it. It's bound to

change so get feedback and make the best changes you can. And get some

elevator speeches ready, you never know when they will come in handy.

In terms of formal stuff this is what you can plan regarding Communication. But

being a good communicator is another completely different topic - and mostly

unrelated to this plan.

Images from http://socialmediamagic.com


Listen with 4 ears

Picture your wife or husband driving you to the airport. You stop at a red light.

After a while the light goes green and so you say: "The light is green". What is

your wife's or husband's most likely reaction? It will probably fit in one of the

following general directions:

She/he resumes driving

She/he says "It's not my fault you forgot your phone and we had to go back to get it"

She/he says "Calm down, I was paying attention this time, the light turned green just now"

She/he says "Don't worry, you'll be there in time"

And now you may be thinking: "Wow, that's right... how can this simple

statement get such different responses?" or maybe "Why should I care?". In

either case, you'll get an answer for both questions in this article.

This article is about the filters set by the people involved in a communication -

the one sending the information (sender) and the one receiving the information

(receiver). These filters are part of a communication model best known as the 4-

ears model (or four-sides model or the communication square) You can check

more on this model on Wikipedia - it's always a good starting point. Basically, the

4-ears model explains how someone says "Nice job" with an angry tone and

everyone hears "You messed it up". It is relevant for Project Managers because,

in general, Project Managers communicate a lot and deal with lots of people.

The filters involved are made of the basic following types:

The fact filter This is the filter that allows you to communicate (send, receive or both) just the

facts, filtering out everything else. There's no criticism here, this is not good or

bad, it's just the way it is, sometimes it's appropriate and sometimes it's not. Just

like the example before, the communication consists on the fact alone that the

light is green. Period. There's no further interpretation or second meaning to it.

It's just like we imagine a computer would communicate. So in the previous

example, the person driving just drives once she/he knows the traffic light is

green.

As a sender, it may sound like a good idea to focus on this filter when you're

presenting something like a project status report on a Steering Committee. The

truth is that many times you have to make use of other tools to really make

people understand what's going on and its impact. Same cases where this is

particular important include Change Management and you can read more about

it here.

As a receiver, the fact filter sounds most useful dealing with a crisis: you just

need the facts to get to a solution, anything else is just noise. Or isn't it?

http://en.wikipedia.org/wiki/Four-sides_model


http://4.bp.blogspot.com/-b_3EsNHzlTc/TuteWCxXrCI/AAAAAAAAAl4/dS3jD8zVNNM/s1600/Green+Light.png


Sometimes solutions are just laying there apart from the facts - like thinking

outside of the box or focusing on interests instead of positions when negotiating.

The self-revealing filter The best example I can think of is a romantic one, like when you say something

such as "It's been a pleasure talking to you" but the rest of you (tone of voice,

touching hands or whatever) complements it such a way that it really

communicates "I'm in love". Mothers know how to apply this filter better than

anyone else. The communication somehow reveals something about the sender

(intentionally or not) that gives another meaning to the actual message being

communicated.

In the previous example, both the sender and receiver know all about the

context of the situation - that the sender remembered he forgot his cell phone at

home when they were half way to the airport - and that turns the communication

into another dimension. In fact, the sender is saying that he's desperate to get at

the airport in time and he/she can use any help available. And the receiver

answers him/her accordingly.

The relationship filter In an extreme, this is the filter you use when you feel so comfortable with

someone that you can be at ease together without saying a word. Have you ever

felt that way? It makes use of past shared experiences to give another meaning

to what's actual being said.

In the previous example, the person driving is always distracted with something,

and both of them know it perfectly well. So when one says "The light is green"

what he/she actually means is "Wake up! You can keep driving now" and the

receiver is defensive and says "Calm down, I was paying attention this time, the

light turned green just now".

The appeal filter This is the filter applied when a statement is in fact an order or a request. Some

people use it when they say the time when they actually mean it's late.

In the previous example, the message is in fact "Hurry up or I'll lose my flight" and

it's answered accordingly "Don't worry, you'll be there in time".

Why should you care? This hopefully answered the first question "How can a simple statement get such

different responses". The next question is now easy to answer: why should a

Project Manager care about the 4-ears model? Project Managers communicate a

lot, both as a sender and a receiver. So the odds that they bump into a mismatch

of filters is significant.

So when you act as a sender, be as explicit as you possibly can about the filters

you're using: just say you're stating the facts when that's what you intend to

communicate; or make an explicit request when that's what you want. Just make

it as explicit as you can, possibly using feedback in the process to make sure that

the communication did take place as you intended (remember George Bernard

Shaw's words: The single biggest problem in communication is the illusion that it

has taken place).

And when you're the receiver, try to capture what people really meant when

they talked to you. This is particularly difficult for me as I'm a facts filter heavy

user, but it can be useful even after the communication took place, maybe when

you're walking the dog. It has proven useful time and time again to me - even

when you don't respond immediately to what people are saying to you. It's a case

where the expression "better late than never" applies.



http://www.ah-ha-moments.net/2010/12/george-bernard-shaw-on-communication_23.html

http://www.ah-ha-moments.net/2010/12/george-bernard-shaw-on-communication_23.html



In conclusion The messages you send and receive have filters, one of them being the actual

facts being transmitted. But there are other 3 - just don't forget about them.

Even if you try to recall conversations at a later time (when you can't do it live),

you can still understand better what people are trying to tell you if you just

remember this. And if you remember this you can communicate a lot better

when you need to pass a message to someone else. Keep this in mind on the next

status meeting or the next email you write to your project team, will you?

It can make a real difference and even make you a better Project Manager!

Images from http://imisioluwa.blogspot.com


How to focus the Pomodoro way

I used to have 2 monitors on my desk, a phone, a smart phone, and several alerts

set on my laptop for email (both my personal and company accounts), Skype, my

company chat software, helpdesk software, monitoring software and, according

to the needs of the moment, several other alerts.

Things got to a point where I was considering getting a third monitor when all of

the sudden it struck me the insanity of all this: how could I get focused on

anything and get anything done? Around this time I bumped into the Pomodoro

Technique and it helped me focus on the tasks at hand. Have you ever heard

about it? Here's a quick guide to help you focus on what you have to do.

Warning

The Pomodoro Technique is not a magic bullet and you don't have to follow it

blindly. My advice to you is that you adapt it to your needs.

It also doesn't address your work environment as it may be expected of you an

instant answer to any particular email - that may be the norm in your office. The

way to deal with that kind of problems goes way beyond the Pomodoro

Technique.

Neither it addresses your values and priorities. And without this direction you

may be very active all right - but working in the wrong direction. And that's not

being productive.

What is it good for?

Francesco Cirillo created the Pomodoro Technique as a way to improve personal

productivity so you can apply this yourself as any member of your project team

can but it's always personal. His objectives, as stated in his free ebook available

for download on his website:

Alleviate anxiety linked to becoming

Enhance focus and concentration by cutting down on interruptions

Increase awareness of your decisions

Boost motivation and keep it constant

Bolster the determination to achieve your goals

Refine the estimation process, both in qualitative and quantitative terms

Improve your work or study process

Strengthen your determination to keep on applying yourself in the face of complex situations

But if you ask me, the objective of using the Pomodoro Technique is to focus on

what you are doing at the moment.

After thinking about this, I found the reason why I had the 2 monitors and all the

alerts on my desk. And the reason was: I can focus for very short periods of time.

And so this was a way to jump from one activity to another without trying to

focus on the same thing for a long time. And it works for me - and the first thing I

did after this was to get rid of all the alerts and the second monitor. I now have

no alerts except the ones I must have (such as my company's chat software).

http://www.pomodorotechnique.com/



http://2.bp.blogspot.com/-TGB0iu8c0CQ/TvRQMcFjR6I/AAAAAAAAAmo/u9Y_ZMbsKKs/s1600/pomodoro.jpg


The process The process is very straight forward and it consists of:

Planning: at the start of the working day to select what will be done during that day

Tracking: all day long to record the necessary metrics to establish your performance

Recording: at the end of the working day to compile and record any worth taking observations

Processing: at the end of the working day to analyse your records

Visualizing: at the end of the working day to put the analized information in graphs

For more details, please check the Pomodoro Technique website.

You should have an Activity Inventory that is updated all the time, as needed.

This is where everything you have to do is recorded. At the beggining of the day,

you select the activities you think you can do during all that day and record them

on another list, the To Do Today. Having that list with you, the rules of the work

are as follows:

Choose the first item in the To Do Today list

Set the timer to 25 minutes

Work on that activity until the timer rings

Mark an X on that activity on the To Do Today list and, if done, mark it also as done

Take a short break (3 to 5 minutes) that should be longer (15 to 30 minutes) every 4 iterations

Repeat this sequence (each sequence is called a Pomodoro)

Interruptions

It's very difficult for me to do a Pomodoro straight from start to finish without

being interrupted: the phone rings or someone asks for this or that. Francesco

Cirillo separates internal distractions from external ones. Internal distractions

are the ones that you originate yourself. The best advice is, when you feel

difficulty in concentrating and start to lose focus, interrupt your Pomodoro and

do something else for a short time, even before you take a break at the end of

the Pomodoro. Go check your personal mail, your news feed or whatever.

There's not much you can do about the external interruptions. What the

Pomodoro Technique offers you is a way to make them visible. Actually 2

different ways:

If you have to do something that you didn't plan to do during that day, set it apart in your To Do Today under an "Unplanned" section

Record each interruption and the reason why (phone call, chat, answer an urgent email or whatever)

By the way, the best remedy I know of to stop your coworkers to interrupt you is

listening to music using headphones. Unfortunately, this doesn't work 100% of

the time but it does reduce a lot the number of interruptions.

How to adapt to your particular case

I actually did something like the Pomodoro Technique while I was in the

university - the longest one single period I was ever able to study straight was 45

minutes. Then I would have to stand, get a coffee or talk to someone, anything to

get my mind off studying. And afterwards I'd go back to it. Not all that different,

is it?



But the Pomodoro Technique, as Francesco Cirillo defines, doesn't work for me

as it is. For instance, how do you select what to do during the day? David Allen's

Getting Things Done covers this bit good enough for me.

One other thing I do is adjust the lenght of each Pomodoro as I find 25 minutes

to be too long. According to the task at hand, I can set a 10 minute Pomodoro or

a 20 minute Pomodoro.

Variable lenght Pomodoros is also something that helps me: I prefer to work on a

single task on each Pomodoro although frequently I have tasks that last several

Pomodoros.

The point is, I had to adapt the process for me. And you should do the same - but

probably not the same way I did.

Conclusion

At the end of the day, productivity is all about doing first the right things for you

and the Pmodoro Technique doesn't help all that much in that sense. But

productivity also requires focus, and in this sense the Pomodoro Technique is

the best thing I know - that works for me. So why not give it a try? Check it out

and tell me how the experience went, will you?

Images from http://www.escolafreelancer.com



Don't judge too quickly

Something like this must have happen to you, right? You jump into conclusions

with partial information and you feel that the conclusion you reached is the

truth. But later you get the rest of the relevant information and find out you

were absolutely wrong. Is this the kind of thing that makes you mad at yourself?

Well, maybe you shouldn't... unless you just trashed a brand new convertible

Mercedes!

Common sense

Earlier this month I wrote a guest post on Michael Greer's blog, PM Resources.

Michael challenged me (and many others) to answer the question "What's the

one simple thing to improve Project Management" and the first thing that came

to mind was "common sense". One of the virtues of common sense is that it

allows us to make fast decisions, the main reason for this being that common

sense doesn't need to be true - you just need to believe that it is true.

We used to believe that the world was flat. And that was OK because that would

answer all our needs. The fact that the world isn't flat wouldn't benefit us in any

way until we had different needs such as sailling long distances.

On the other hand, if you try to dig into all the facts and explain everything to be

sure where the truth lies, you won't get much work done - if any at all. Not

explaining everything allows us to react much faster to everything around us.

But sometimes you are wrong

Like the man in the video, sometimes you find out you were wrong. And this is

the tricky part: to be aware and check when you need to re-calibrate your own

common sense. In a way, the man in the video was lucky because he did find he

was wrong - and this is something that doesn't always happen. But assuming you

were wrong, how do you deal with it? The easy answer is to adapt when your

common sense doesn't seem to work any more in any particular situation - and

so you dig a little bit deeper. But common sense is, amongst other things, a set of

beliefs. How easy can it be to question your own beliefs?

Re-calibrating your beliefs...

A good example of this is when you're working with people from other cultures.

A lot of what you see going on doesn't seem right to you. For instance, you may

be used to start meetings exactly at the scheduled time. But time after time you

see that people show up 10 or 15 minutes later - and that may seem to you as a

sign that they don't respect you or/and your work. On every such meeting, you

enforced the need to start the meetings on time and everyone seemed to agree

but on the next meeting everyone is late just the same.

There are 2 ways to deal with this, equally valid. You can force the meetings to

start on time or you can adapt to the local culture. Both have risks and benefits

associated to them, so there's no single answer to this.

What makes this particularly difficult is that you're so used to explaining things

the way you do that it never occurs to you that you may have another

perspective on the subject.

...Your own way

http://michaelgreer.biz/?p=3636


You can try to force meetings to start on time by being on the meeting room on

time and by starting the meeting as soon as someone else gets there. Anyone

arriving late to a running meeting has lost something already and that's

something no one likes (another assumption in the common sense style - but it

has worked for me so far), so the the odds are that the next meeting people will

be on time. Unless, and this is the risky part, that people get offended by this

attitude - and it can happen.

...Or adapting yourself

If you decide to adapt to the local culture, the best thing is to be sure you

understand it. One way to do this is to explain your problem to someone you

trust enough to clarify and explain to you how things work - which may not be

easy. I have the perfect story to illustrate this. I have a friend who was invited by

a friend of his to visit him almost on the opposite side of the planet. The first time

they went out for dinner, my friend ate everything that was served in an attitude

intended to show that he enjoyed the meal. But after they all finished his friend

took him to yet another restaurant to have dinner again! He did try to get some

reason for this but that took him nowhere - and got no explanation for a second

dinner. But something was definately wrong, so my friend watched closely how

others behaved at the table and noticed they all left some food in an attitude

intended to show they were full and already had everything they could. So he did

the same. Problem solved.

And the point is...

...That you must use common sense and you must be wrong from time to time.

That is not important, not even relevant. What is relevant and important is what

you do when you're wrong: do you blame someone else? Or can you question

your beliefs?


Quotes

G. K. Chesterton on Leadership and Teams

Human nature simply cannot subsist without a hope and aim of some kind.

In "Heretics", 1905. Gilbert Keith Chesterton (1874–1936) was an English writer sometimes called the "prince of paradox".

Sun Tzu on Teams

Too frequent rewards indicate that the

general is at the end of his resources;

too frequent punishments that he is in

acute distress.

In "The Art of War". Sun Tzu (544-496 BC) was a Chinese military general, strategist and philosopher.

Nanny McPhee on Teams

When you need me,

but do not want me,

then I will stay.

In "Nanny McPhee" (2005). Nanny McPhee is a 2005 fantasy film starring Emma Thompson.

Babe Ruth on Teams

The way a team plays as a whole determines its

success. You may have the greatest bunch of individual stars in the world, but if they don't play

together, the club won't be worth a dime.

In "Great Quotes to Inspire Great Teachers" (2001) by Noah BenShea. Babe Ruth (1895-1948), was an American Major League Baseball player from 1914 to 1935, named as the greatest baseball player in history in various surveys and rankings.

http://www.ah-ha-moments.net/2011/01/g-k-chesterton-on-leadership-and-teams.html

http://en.wikipedia.org/wiki/G._K._Chesterton

http://www.ah-ha-moments.net/2011/01/sun-tzu-on-teams.html

http://www.ah-ha-moments.net/2011/01/nanny-mcphee-on-teams.html

http://www.ah-ha-moments.net/2011/01/babe-ruth-on-teams.html

http://en.wikipedia.org/wiki/Babe_Ruth

http://2.bp.blogspot.com/_yRrxfYiMBlo/TRfTyd8IYXI/AAAAAAAAAWE/q26RIKGf9tw/s1600/GKChesterton.jpg


Thomas Edison on Planning

Just because something doesn't do what you

planned it to do doesn't mean it's useless.

In "Artifacts: An Archaeologist's Year in Silicon Valley" (2001) by Christine Finn. Thomas Edison (1847-1931), an American inventor and businessman who developed many devices which greatly influenced life worldwide into the 21st century.

Leonardo da Vinci on Teams

The part always has a tendency to reunite with its

whole in order to escape from its imperfection.

In "Notebook XIX". Leonardo da Vinci (1452–1519) was an Italian polymath: painter, sculptor, architect, musician, scientist, mathematician, engineer, inventor, anatomist, geologist, cartographer, botanist and writer.

John Lennon on Planning

Life is what happens to you,

while you're busy making other plans

in From Beautiful Boy (Darling Boy) off the 1980 "Double Fantasy" album. John Lennon (1940–1980) was an English musician and singer-songwriter who rose to worldwide fame as one of the founding members of The Beatles.

Abraham Maslow on Tools

I suppose it is tempting,

if the only tool you have is a hammer,

to treat everything as if it were a nail.

in The Psychology of Science: A Reconnaissance (1966). Abraham Maslow (1908–1970), was an American professor of psychology at Brandeis University who founded humanistic psychology and created Maslow's hierarchy of needs.

http://www.ah-ha-moments.net/2011/01/thomas-edison-on-planning.html

http://en.wikipedia.org/wiki/Thomas_edison

http://www.ah-ha-moments.net/2011/01/leonardo-da-vinci-on-teams.html

http://en.wikipedia.org/wiki/Leonardo_da_Vinci

http://www.ah-ha-moments.net/2011/01/john-lennon-on-planning.html

http://en.wikipedia.org/wiki/John_Lennon

http://www.ah-ha-moments.net/2011/02/abraham-maslow-on-tools.html

http://en.wikipedia.org/wiki/Abraham_Maslow


Ken Blanchard on Communication

Feedback is the breakfast of champions.

Attributed to Ken Blanchard. Kenneth Hartley Blanchard (1939-) is an American author and management expert.

Stephen Covey on Ethics

Our ultimate freedom is the right and power to decide how anybody or anything outside us will

affect us.

In Principle-Centered Leadership, 1992. Stephen Covey (1932-), is the author of the best-selling book "The Seven Habits of Highly Effective People"

William Jennings Bryan on Leadership

Destiny is not a matter of chance; it is a

matter of choice.

It is not a thing to be waited for; it is a

thing to be achieved.

In a speech delivered on February 22, 1899. William Jennings Bryan (1860–1925), was an American politician in the late-19th and early-20th centuries. He was a dominant force in the liberal wing of the Democratic Party, standing three times as its candidate for President of the United States.

Plato on Leadership

Never discourage anyone who continually makes

progress, no matter how slow.

Plato (428/427 BC–348/347 BC) was a Classical Greek philosopher, mathematician, student of Socrates, writer of philosophical dialogues, and founder of the Academy in Athens, the first institution of higher learning in the Western world.

http://www.ah-ha-moments.net/2011/02/ken-blanchard-on-communication.html

http://en.wikipedia.org/wiki/Ken_Blanchard

http://www.ah-ha-moments.net/2011/02/stephen-covey-on-ethics.html

http://en.wikipedia.org/wiki/Stephen_Covey

http://en.wikipedia.org/wiki/Stephen_Covey

http://www.ah-ha-moments.net/2011/02/william-jennings-bryan-on-leadership.html

http://en.wikipedia.org/wiki/William_Jennings_Bryan

http://www.ah-ha-moments.net/2011/03/plato-on-leadership.html

http://en.wikipedia.org/wiki/Plato


Parkinson on Time Management

Work expands so as to fill the time available for

its completion.

In Parkinson's Law (1958), based on an article published in The Economist in November 1955. Cyril Northcote Parkinson (1909–1993), was a British naval historian and author of some sixty books, the most famous of which was his bestseller Parkinson's Law, which led him to be also considered as an important scholar within the field of public administration.

Napolean on Leadership

From the sublime to the ridiculous is but a

step.

In a letter to Abbé du Pradt (1812). Napoleon Bonaparte (1769–1821), was a military and political leader of France and Emperor of the French as Napoleon I, whose actions shaped European politics in the early 19th century.

Friedrich Nietzsche on Leadership

So it is that punishment tames man, but does not

make him "better".

In "On the Genealogy of Morality" (1887). Friedrich Nietzsche (1844–1900), was a German philosopher, whose critiques of contemporary culture, religion, and philosophy centered on a basic question regarding the foundation of values and morality.

Frank Zappa on basic concepts

Information is not knowledge.

Knowledge is not wisdom.

Wisdom is not truth.

Frank Zappa in the song Packard Goose on the album Joe's Garage: Act III (1979). Frank Zappa (1940–1993) was an American composer, singer-songwriter, electric guitarist, record producer, and film director.

http://www.ah-ha-moments.net/2011/03/parkinson-on-time-management.html

http://en.wikipedia.org/wiki/C._Northcote_Parkinson

http://www.ah-ha-moments.net/2011/03/napolean-on-leadership.html

http://en.wikipedia.org/wiki/Napoleon_Bonaparte

http://en.wikipedia.org/wiki/Napoleon_Bonaparte

http://www.ah-ha-moments.net/2011/03/friedrich-nietzsche-on-leadership.html

http://en.wikipedia.org/wiki/Friedrich_Nietzsche

http://www.ah-ha-moments.net/2011/03/frank-zappa-on-basic-concepts.html

http://en.wikipedia.org/wiki/Frank_Zappa


Fernando Pessoa on Initiation

All beginnings are involuntary.

In Message (1934). Fernando Pessoa (1888-1935) was a Portuguese poet, writer, literary critic and translator.

Isaac Newton on Leadership

If I have seen farther than others, it is because I

was standing on the shoulder of giants.

Sir Isaac Newton in a letter to Robert Hooke (1676). Isaac Newton (1643-1727), was an English physicist, mathematician, astronomer, natural philosopher, alchemist, and theologian.

Baruch Spinoza on Teams

There is no individual thing in nature.

Baruch Spinoza in Ethics (1677). Baruch Spinoza, aka Bento de Spinoza (1632-1677), was a social and metaphysical philosopher who was excommunicated from the Jewish community of his native Amsterdam.

T.S. Eliot on Risk

Only those who will risk going too far can

possibly find out how far one can go.

T.S. Eliot in the Preface to Transit of Venus: Poems by Harry Crosby (1931). T.S. Eliot (1888-1965), was an American-born English poet, playwright, and literary critic.

http://www.ah-ha-moments.net/2011/03/fernando-pessoa-on-initiation.html

http://en.wikipedia.org/wiki/Fernando_Pessoa

http://www.ah-ha-moments.net/2011/03/isaac-newton-on-leadership.html

http://en.wikipedia.org/wiki/Isaac_Newton

http://www.ah-ha-moments.net/2011/03/there-is-no-individual-thing-in-nature.html

http://en.wikipedia.org/wiki/Baruch_Spinoza

http://en.wikipedia.org/wiki/Baruch_Spinoza

http://www.ah-ha-moments.net/2011/03/ts-eliot-on-risk.html

http://en.wikipedia.org/wiki/T._S._Eliot

http://en.wikipedia.org/wiki/T._S._Eliot


John Fitzgerald Kennedy on Personal Management

The greater our knowledge increases

the greater our ignorance unfolds.

John Fitzgerald Kennedy in a speech in 1962. John Fitzgerald Kennedy (1917-1963) was the 35th President of the United States.

Floyd Patterson on Personal Management

They said I was the fighter who got

knocked down the most,

but I also got up the most.

Floyd Patterson after fighting Ingemar Johansson in 1960. Floyd Patterson (1935-2006) was an American 2-time world heavyweight boxing champion.

Martin Luther King, Jr. on Communication

A riot is the language of the unheard.

Martin Luther King, Jr. in a speach in 1963. Martin Luther King, Jr. (1929-1968), was an American clergyman, activist, and prominent leader in the African American civil rights movement.

E. B. White on rules

The best writers sometimes disregard the

rules of rhetoric.

E. B. White in the Introduction of "The elements of style" by William Strunk Jr. and E. B. White

http://www.ah-ha-moments.net/2011/04/john-fitzgerald-kennedy-on-personal.html

http://en.wikipedia.org/wiki/John_Kennedy



http://www.ah-ha-moments.net/2011/04/floyd-patterson-on-personal-management.html

http://en.wikipedia.org/wiki/Floyd_Patterson

http://en.wikipedia.org/wiki/Floyd_Patterson

http://www.ah-ha-moments.net/2011/04/martin-luther-king-jr-on-communication.html

http://en.wikipedia.org/wiki/Martin_Luther_King_Jr.

http://en.wikipedia.org/wiki/Martin_Luther_King_Jr.

http://www.ah-ha-moments.net/2011/05/e-b-white-on-rules.html

http://en.wikipedia.org/wiki/E.B._White

http://en.wikipedia.org/wiki/E.B._White


Walt Disney on Stakeholders

We're not trying to entertain the

critics...

I'll take my chances with the public.

Walt Disney in "Disneyland, 1955: Just Take the Santa Ana Freeway to the American Dream" by Karal Ann Marling. Walt Disney (Walter Elias Disney) (1901–1966) was an American film producer, director, screenwriter, voice actor, animator, entrepreneur, entertainer, international icon, and philanthropist.

Edward Phelps on Failure

The man who makes no mistakes

does not usually make anything.

Edward John Phelps in a speech given at the Mansion House in London on 1899. Edward John Phelps (1822-1900) was a lawyer and diplomat from Vermont. From 1851 to 1853 he was the second controller of the United States Treasury.

Galileo Galilei on Discovery

All truths are easy to understand once they

are discovered; the point is to discover them.

Galileo Galilei as quoted by Melissa Giovagnoli in "Angels in the workplace : stories and inspirations for creating a new world of work" (1999). Galileo Galilei (1564–1642) was an Italian physicist, mathematician, astronomer and philosopher who played a major role in the Scientific Revolution.

George Santayana on Lessons Learned

Those who cannot remember the

past

are condemned to repeat it.

In "The Life of Reason" (1905-1906). George Santayana (1863-1952) was a Spanish American philosopher, essayist, poet, and novelist.

http://www.ah-ha-moments.net/2011/05/walt-disney-on-stakeholders.html

http://en.wikipedia.org/wiki/Walt_Disney

http://en.wikipedia.org/wiki/Walt_Disney

http://www.ah-ha-moments.net/2011/06/edward-phelps-on-failure.html

http://en.wikipedia.org/wiki/Edward_John_Phelps

http://en.wikipedia.org/wiki/Edward_John_Phelps

http://www.ah-ha-moments.net/2011/06/galileo-galilei-on-discovery.html

http://en.wikipedia.org/wiki/Galileo_Galilei

http://en.wikipedia.org/wiki/Galileo_Galilei

http://www.ah-ha-moments.net/2011/06/george-santayana-on-lessons-learned.html

http://en.wikipedia.org/wiki/George_Santayana

http://en.wikipedia.org/wiki/George_Santayana


Seneca on Planning

When a man does not know what

harbor he is making for,

no wind is the right wind.

In "Moral Letters to Lucilius". Lucius Annaeus Seneca (ca. 4 BCE – 65 CE) was a Roman Stoic philosopher, statesman, dramatist, and in one work humorist, of the Silver Age of Latin literature. He was tutor and later advisor to emperor Nero.

Saint Exupéry on Communication

Language is the source of

misunderstandings.

In "The Little Prince" (1943). Antoine de Saint Exupéry (1900-1944) was a French writer and aviator. He is best remembered for his novella "The Little Prince" (Le Petit Prince) and for his books about aviation adventures, including "Night Flight" and "Wind, Sand and Stars".

Heinlein on Laziness

Progress doesn't come from early risers — progress is made by lazy men looking for

easier ways to do things.

In "Time enough for love" (1973). Robert Heinlein (1907-1988) was an American science fiction writer. Often called the "dean of science fiction writers", Heinlein, Isaac Asimov and Arthur C. Clarke were known as the "Big Three" of science fiction.

Voltaire on Quality

The better is the enemy of the good.

In "La Bégueule" (1772). François-Marie Arouet (1694–1778), better known by the pen name Voltaire, was a French Enlightenment writer, historian and philosopher famous for his wit and for his advocacy of civil liberties, including freedom of religion and free trade.

http://www.ah-ha-moments.net/2011/07/seneca-on-planning.html

http://en.wikipedia.org/wiki/Seneca_the_Younger

http://en.wikipedia.org/wiki/Seneca_the_Younger

http://www.ah-ha-moments.net/2011/08/saint-exupery-on-communication.html

http://en.wikipedia.org/wiki/Antoine_de_Saint_Exup%C3%A9ry

http://en.wikipedia.org/wiki/Antoine_de_Saint_Exup%C3%A9ry

http://www.ah-ha-moments.net/2011/08/heinlein-on-laziness.html

http://en.wikipedia.org/wiki/Robert_A._Heinlein

http://en.wikipedia.org/wiki/Robert_A._Heinlein

http://www.ah-ha-moments.net/2011/09/voltaire-on-quality.html

http://en.wikipedia.org/wiki/Voltaire

http://en.wikipedia.org/wiki/Voltaire


Joanna Baillie on Change

The brave man is not he who feels no fear,

For that were stupid and irrational; But he, whose noble soul its fear subdues,

And bravely dares the danger nature shrinks from.

In "Count Basil" (1798). Joanna Baillie (1762–1851) was a Scottish poet and dramatist.

Oscar Wilde on Lessons Learned

What a pity that in life

we only get our lessons

when they are of no use to us.

In "Lady Windermere's Fan" (1892). Oscar Wilde (1854–1900) was an Irish playwright, poet and author of essays and novels.

Isaac Asimov on Ethics

Never let your sense of morals

prevent you from doing what is

right.

In "The Foundation series" (1942/4). Isaac Asimov (1920–1992) was an American author and professor of biochemistry at Boston University, best known for his works of science fiction and for his popular science books..

Mark Twain on Ethics

If you tell the truth

you don't have to remember

anything.

In his notebook on 1894 published as "Mark Twain's Notebook" (1935). Mark Twain (1835–1910) was born Samuel Langhorne Clemens and he was an American author and humorist. He is most noted for his novels, The Adventures of Tom Sawyer (1876), and its sequel, Adventures of Huckleberry Finn (1885), the latter often called "the Great American Novel."

http://www.ah-ha-moments.net/2011/09/joanna-baillie-on-change.html

http://en.wikipedia.org/wiki/Joanna_Baillie

http://www.ah-ha-moments.net/2011/09/oscar-wilde-on-lessons-learned.html

http://en.wikipedia.org/wiki/Oscar_Wilde

http://en.wikipedia.org/wiki/Oscar_Wilde

http://www.ah-ha-moments.net/2011/09/isaac-asimov-on-ethics.html

http://en.wikipedia.org/wiki/Isaac_Asimov

http://en.wikipedia.org/wiki/Isaac_Asimov

http://www.ah-ha-moments.net/2011/09/mark-twain-on-ethics.html

http://en.wikipedia.org/wiki/Mark_Twain


General Lee on Control

I cannot consent to place in the

control of others

one who cannot control himself.

In "Personal Reminiscences, Anecdotes, and Letters of Gen. Robert E. Lee" (1874) by John William Jones. Gen. Robert E. Lee (1807–1870) was a career military officer who is best known for having commanded the Confederate Army of Northern Virginia in the American Civil War.

H.G. Wells on Change

Adapt or perish, now as ever,

is Nature's inexorable imperative.

In "A Short History of the World" (1922). Herbert George Wells (1866–1946) was an English author, now best known for his work in the science fiction genre.

Aldous Huxley on Lessons Learned

That men do not learn very much from the lessons of history is the most important of

all the lessons that history has to teach.

In "Case of Voluntary Ignorance", Collected Essays (1959). Aldous Huxley (1894-1963) was an English writer best known for his novels including Brave New World.

Louis V. Gerstner, Jr. on Productivity

Never confuse activity with results.

Louis V. Gerstner, Jr. (1942-) was chairman of the board and chief executive officer of IBM from 1993 until 2002.

http://www.ah-ha-moments.net/2011/09/general-lee-on-control.html

http://en.wikipedia.org/wiki/Robert_E._Lee

http://www.ah-ha-moments.net/2011/09/hg-wells-on-change.html

http://en.wikipedia.org/wiki/H._G._Wells

http://www.ah-ha-moments.net/2011/09/aldous-huxley-on-lessons-learned.html

http://en.wikipedia.org/wiki/Aldous_Huxley

http://www.ah-ha-moments.net/2011/10/louis-v-gerstner-jr-on-productivity.html

http://en.wikipedia.org/wiki/Louis_V._Gerstner_Jr


Benjamin Franklin on Lessons Learned

Love your Enemies, for they tell you

your Faults.

In Poor Richard's Almanack (1756). Benjamin Franklin (1706–1790) was one of the Founding Fathers of the United States. A noted polymath, Franklin was a leading author, printer, political theorist, politician, postmaster, scientist, musician, inventor, satirist, civic activist, statesman, and diplomat.

Alan Mulally on Escalation

You can't manage a secret.

As reported on How Ford Profits from its '24 Hour Rule'. Alan Mulally (1945-) is an American engineer and businessman who is currently the President and Chief Executive Officer of the Ford Motor Company.

Vince Lombardi on Leadership

Leadership is not just one quality, but

rather a blend of many qualities.

In "Vince Lombardi on Coaching and Leadership" (2001). Vince Lombardi (1913–1970) was an American football coach. He is best known as the head coach of the Green Bay Packers during the 1960s.

Superman on (poor) Communication

Statistically speaking, of course, it's still the safest way to travel.

Superman talking about flying after an helicopter crash in "Superman: The Movie" (1978). This film is an American-British superhero film based on the DC Comics character of the same name. Richard Donner directed the film, which stars Christopher Reeve as Superman.

http://www.ah-ha-moments.net/2011/10/benjamin-franklin-on-lessons-learned.html

http://en.wikipedia.org/wiki/Benjamin_Franklin

http://www.ah-ha-moments.net/2011/10/alan-mulally-on-escalation.html

http://blogs.hbr.org/cs/2010/12/how_ford_24_hour_rule.html

http://blogs.hbr.org/cs/2010/12/how_ford_24_hour_rule.html

http://en.wikipedia.org/wiki/Alan_Mulally

http://www.ah-ha-moments.net/2011/10/vinve-lombardi-on-leadership.html

http://en.wikipedia.org/wiki/Vince_lombardi

http://www.ah-ha-moments.net/2011/10/superman-on-poor-communication.html

http://en.wikipedia.org/wiki/Superman_%28movie%29


Mozart on Personal Skills

All I insist on, and nothing else,

is that you should show the whole world that you are not afraid.

Wolfgang Amadeus Mozart in a letter as published in "The Letters of Mozart & His Family" (1938). Mozart (1756–1791), was a prolific and influential composer of the Classical era.

Theodore von Kármán on Crashing

Everyone knows it takes a woman

nine months to have a baby.

But you Americans think if you get

nine women pregnant,

you can have a baby in a month.

Quoted from "The Life and Times of Joe Gordon (To the Best of My Recollection)" by Joseph G. Martin (2007). Theodore von Kármán (1881–1963) was a Hungarian-born engineer and physicist who was active primarily in the fields of aeronautics during the seminal era in the 1940s and 1950s.

Fred Brooks on Crashing

Brooks's Law:

Adding manpower to a late software project makes it later.

In "The Mythical Man-Month: Essays on Software Engineering" (1975). Fred Brooks (1931-) is a software engineer and computer scientist, best known for managing the development of IBM's System/360 family of computers and the OS/360 software support package, then later writing candidly about the process in his seminal book The Mythical Man-Month.

Dostoevsky on Ethics

If you want to be respected by others the great thing is to respect yourself.

In "The Insulted and the Injured" (1861). Fyodor_Dostoevsky (1821–1881) was a Russian writer of novels, short stories and essays. He is best known for his novels Crime and Punishment, The Idiot and The Brothers Karamazov.

http://www.ah-ha-moments.net/2011/10/mozart-on-personal-skills.html

http://en.wikipedia.org/wiki/Wolfgang_Amadeus_Mozart

http://en.wikipedia.org/wiki/Wolfgang_Amadeus_Mozart

http://www.ah-ha-moments.net/2011/10/theodore-von-karman-on-crashing.html

http://en.wikipedia.org/wiki/Theodore_von_K%C3%A1rm%C3%A1n

http://en.wikipedia.org/wiki/Theodore_von_K%C3%A1rm%C3%A1n

http://www.ah-ha-moments.net/2011/10/fred-brooks-on-crashing.html

http://en.wikipedia.org/wiki/Fred_Brooks

http://www.ah-ha-moments.net/2011/10/dostoevsky-on-ethics.html

http://en.wikipedia.org/wiki/Fyodor_Dostoevsky


Muhammad Ali on Win-Win

In a competition of love we'll all share in

the victory, no matter who comes first.

In "The Soul of a Butterfly" (2004). Muhammad Ali (1942-) is an American boxer who was the Heavyweight Champion of the World three times between 1964 and 1979.

Richard Feynman on Teams

The highest forms of understanding we

can achieve are laughter and human compassion.

In "What Do You Care What Other People Think?" (1988). Richard Feynman (1918–1988) was an American physicist known for his work in the path integral formulation of quantum mechanics, the theory of quantum electrodynamics and the physics of the superfluidity of supercooled liquid helium, as well as in particle physics (he proposed the parton model).

Helen Keller on Teams

Tolerance is the first principle of

community.

In "Optimist" (1903). Helen Keller (1880–1968) was an American author, political activist, and lecturer. She was the first deafblind person to earn a Bachelor of Arts degree.

John Cleese on Teams

It's almost impossible to maintain any kind of distance or any sense of social

hierarchy when you're just howling with laughter.

In "The Human Face", BBC Television (2001). John Cleese (1939-) is an English actor, comedian, writer, and film producer. In the late 1960s he became a member of Monty Python.

http://www.ah-ha-moments.net/2011/11/muhammad-ali-on-win-win.html

http://en.wikipedia.org/wiki/Muhammad_Ali

http://www.ah-ha-moments.net/2011/11/richard-feynman-on-teams.html

http://en.wikipedia.org/wiki/Richard_Feynman

http://www.ah-ha-moments.net/2011/11/helen-keller-on-teams.html

http://en.wikipedia.org/wiki/Helen_Keller

http://www.ah-ha-moments.net/2011/11/john-cleese-on-teams.html

http://en.wikipedia.org/wiki/John_Cleese


Warren Buffett on Available Funds

Just as work expands to fill available time,

corporate projects or acquisitions will materialize to soak up available funds...

In his 1989 "Chairman's letter". Warren Buffet (1930-) is an American business magnate, investor, and philanthropist. He is widely regarded as one of the most successful investors in the world.

Ernest Hemingway on Ethics

All things truly wicked start from an

innocence.

In "A Moveable Feast" (1964). Ernest Hemingway (1899-1961) was an American author and journalist. Hemingway produced most of his work between the mid-1920s and the mid-1950s, winning the Nobel Prize in Literature in 1954.

Joseph Conrad on Lessons Learned

It's only those who do nothing that make

no mistakes.

In "An Outcast of the Islands" (1896). Joseph Conrad (1857–1924) was a Polish-born English novelist. Conrad was a master prose stylist who brought a distinctly non-English tragic sensibility into English literature.

António Oliveira Salazar on Sponsorship

In politics, what appears is.

In "Salazar seen the Brazilian anthology of texts of Brazilian and Portuguese authors: anthology of texts of Brazilian and Portuguese authors" (by Armando Pinto, 1962). António de Oliveira Salazar (1889–1970) served as the Prime Minister of Portugal from 1932 to 1968. He also served as acting President of the Republic briefly in 1951. He founded and led the Estado Novo, the authoritarian, right-wing government that presided over and controlled Portugal from 1932 to 1974.

http://www.ah-ha-moments.net/2011/11/warren-buffett-on-available-funds.html

http://en.wikiquote.org/wiki/Warren_Buffet

http://en.wikiquote.org/wiki/Warren_Buffet

http://www.ah-ha-moments.net/2011/11/ernest-hemingway-on-ethics.html

http://en.wikipedia.org/wiki/Ernest_Hemingway

http://en.wikipedia.org/wiki/Ernest_Hemingway

http://www.ah-ha-moments.net/2011/11/joseph-conrad-on-lessons-learned.html

http://en.wikipedia.org/wiki/Joseph_Conrad

http://www.ah-ha-moments.net/2011/11/antonio-oliveira-salazar-on-sponsorship.html

http://en.wikipedia.org/wiki/Ant%C3%B3nio_de_Oliveira_Salazar


Emiliano Zapata on Ethics

I want to die a slave to principles. Not to

men.

In "Heroes of Mexico" (by Morris Rosenblum, 1969). Emiliano Zapata (1879–1919) was a leading figure in the Mexican Revolution, which broke out in 1910, and which was initially directed against the president Porfirio Díaz. He formed and commanded an important revolutionary force, the Liberation Army of the South, during the Mexican Revolution.

Laozi on Leadership

A leader is best when people barely know

that he exists.

In "Tao Te Ching". Laozi (c. 6th-5th century BC) was a mystic philosopher of ancient China, best known as the author of the Tao Te Ching (often simply referred to as Laozi). His association with the Tao Te Ching has led him to be traditionally considered the founder of Taoism.

George Jessel on Leadership

I may be wrong, and often am, but I never

doubt.

Replying to Lord Coleridge's question, "Have you no doubts about it, Jessel?" Lord George Jessel (1824–1883) was a British judge. He was one of the most influential commercial law and equity judges of his time, and served as the Master of the Rolls.

Miguel de Cervantes on Lessons Learned

Time ripens all things. No man is born

wise.

In "Don Quixote de la Mancha" (1605-1615). Miguel de Cervantes (1547-1616) was a Spanish novelist, poet, and playwright. His magnum opus, Don Quixote, considered the first modern novel, is a classic of Western literature, and is regarded amongst the best works of fiction ever written.

http://www.ah-ha-moments.net/2011/11/emiliano-zapata-on-ethics.html

http://en.wikipedia.org/wiki/Emiliano_Zapata

http://www.ah-ha-moments.net/2011/12/laozi-on-leadership.html

http://en.wikipedia.org/wiki/Lao_Zi

http://www.ah-ha-moments.net/2011/12/george-jessel-on-leadership.html

http://en.wikipedia.org/wiki/George_Jessel_%28jurist%29

http://en.wikipedia.org/wiki/George_Jessel_%28jurist%29

http://www.ah-ha-moments.net/2011/12/miguel-de-cervantes-on-lessons-learned.html

http://en.wikipedia.org/wiki/Miguel_de_Cervantes


Alan Kay on Leadership

The best way to predict the future is to

invent it.

In a Palo Alto Research Center meeting (1971). Alan Kay (1940-) is an American computer scientist, known for his early pioneering work on object-oriented programming and windowing graphical user interface design.

Steve Jobs on Innovation

Everything around you that you call

life was made up by people

that were no smarter than you.

In an interview conducted by the Santa Clara Valley Historical Association (1995). Steve Jobs (1955–2011) was an American businessman and inventor widely recognized as a charismatic pioneer of the personal computer revolution.

Zeno of Citium on Communication

We have two ears and one mouth,

so we should listen more than we

say.

As quoted by Diogenes Laërtius. Zeno of Citium (334 BC – 262 BC) was a Greek philosopher from Cyprus, and was the founder of the Stoic school of philosophy which he taught in Athens, from about 300 BC.

Robert Noyce on Innovation

Innovation is everything.

In "The innovators: rediscovering America's creative energy" by James W. Botkin, Dan Dimancescu and Ray Stata (1984). Robert Noyce (1927–1990), nicknamed "the Mayor of Silicon Valley", co-founded Fairchild Semiconductor in 1957 and Intel Corporation in 1968. He is also credited (along with Jack Kilby) with the invention of the integrated circuit or microchip which fueled the personal computer revolution and gave Silicon Valley its name.

http://www.ah-ha-moments.net/2011/12/alan-kay-on-leadership.html

http://en.wikipedia.org/wiki/Alan_Kay

http://www.ah-ha-moments.net/2011/12/steve-jobs-on-innovation.html

http://www.youtube.com/watch?v=UvEiSa6_EPA

http://en.wikipedia.org/wiki/Steve_jobs

http://www.ah-ha-moments.net/2011/12/zeno-of-citium-on-communication.html

http://en.wikipedia.org/wiki/Zeno_of_Citium

http://en.wikipedia.org/wiki/Zeno_of_Citium

http://www.ah-ha-moments.net/2011/12/robert-noyce-on-innovation.html

http://en.wikipedia.org/wiki/Robert_Noyce

http://en.wikipedia.org/wiki/Robert_Noyce


Anatole France on Planning

To accomplish great things we must

not only act, but also dream; not

only plan, but also believe.

In "Discours de réception, Séance De L'académie Française (introductory speech at a session of the French Academy)" (1896). Anatole France (1844–1924) was a French poet, journalist, and novelist. He was a member of the Académie Française, and won the Nobel Prize for Literature in recognition of his literary achievements.

http://www.ah-ha-moments.net/2011/12/anatole-france-on-planning.html

http://en.wikipedia.org/wiki/Anatole_France


Contents

About this Yearbook ................................................................................................ 2

Articles .................................................................................................................... 3

Marketing Process for Project Management ................................................. 3

How to solve communication problems ......................................................... 6

What is a successful project? - Guest post on pmosig ................................... 9

Our iceberg is melting by John Kotter and Holger Rathgeber ...................... 10

AHA! Skipping Change Management is Poor Customer Service by Margaret

Meloni .......................................................................................................... 12

Is focus what you really need? ..................................................................... 14

Aha Moment: Technical People need Project Managers by John Bauer ..... 17

The Art of Funding and Implementing Ideas ................................................ 19

My Ah-Ha! Moment by Pam Stanton ........................................................... 21

ScrumBut is a good think after all ................................................................ 23

Michiko Diby's Ah Ha Moment ..................................................................... 26

Project in your Pocket, by Gareth John Turner ............................................ 28

Beginners Guide to Project Management Part 01 What is Project

Management ................................................................................................ 29

Sam Palani's Ah Ha Moment ........................................................................ 32

Project Sponsorship, by Randall Englund and Alfonso Bucero ..................... 33

Beginners Guide to Project Management Part 02 Context for Project

Management ................................................................................................ 35

Getting to Yes ............................................................................................... 38

Beginners Guide to Project Management Part 03 Where to start ............... 40

Beginners Guide to Project Management Part 04 What to do .................... 42

Hunting for Shark's Teeth and Project Management by Neville Carson ...... 44

PMI Global EMEA Congress, Dublin 2011 ..................................................... 46

Beginners Guide to Project Management Part 05, Case Study - The Project

Charter .......................................................................................................... 48

Managing up ................................................................................................. 52

Binfire: Project Management & Collaboration Tools ................................... 54

Getting Things Done ..................................................................................... 56

Beginners Guide to Project Management Part 06, The Project Management

Plan ............................................................................................................... 60

Beginners Guide to Project Management Part 07, The Work Breakdown

Structure ....................................................................................................... 62

One way to lower the project overall risk is... .............................................. 66

3 Myth Busters on Delegation ...................................................................... 68

Delegation How To ....................................................................................... 71

Beginners Guide to Project Management Part 08, The Gantt Chart ............ 74

There's No Such Thing as "My" Project, by Michael Greer .......................... 77

How to give feedback ................................................................................... 80

Copycats, that's what we all are ................................................................... 84

Beginners Guide To Project Management Part 9, Getting a Project Team .. 86

How to run meetings .................................................................................... 89


International Project Management Day and non-Project Managers ........... 92

Are you a Professional Volunteer? You're needed in Project Management!

...................................................................................................................... 94

Beginners Guide To Project Management Part 10, The Project Budget ...... 97

Stress free Project Managers... .................................................................. 101

Capturing project success ........................................................................... 104

Beginners Guide To Project Management Part 11, The Project

Communication Plan .................................................................................. 106

Listen with 4 ears........................................................................................ 109

How to focus the Pomodoro way ............................................................... 112

Don't judge too quickly .............................................................................. 115

Quotes ................................................................................................................. 117

G. K. Chesterton on Leadership and Teams ............................................... 117

Sun Tzu on Teams ....................................................................................... 117

Nanny McPhee on Teams ........................................................................... 117

Babe Ruth on Teams................................................................................... 117

Thomas Edison on Planning ........................................................................ 118

Leonardo da Vinci on Teams ...................................................................... 118

John Lennon on Planning ........................................................................... 118

Abraham Maslow on Tools ......................................................................... 118

Ken Blanchard on Communication ............................................................. 119

Stephen Covey on Ethics ............................................................................ 119

William Jennings Bryan on Leadership ....................................................... 119

Plato on Leadership .................................................................................... 119

Parkinson on Time Management ............................................................... 120

Napolean on Leadership ............................................................................. 120

Friedrich Nietzsche on Leadership ............................................................. 120

Frank Zappa on basic concepts................................................................... 120

Fernando Pessoa on Initiation .................................................................... 121

Isaac Newton on Leadership ...................................................................... 121

Baruch Spinoza on Teams ........................................................................... 121

T.S. Eliot on Risk.......................................................................................... 121

John Fitzgerald Kennedy on Personal Management .................................. 122

Floyd Patterson on Personal Management ................................................ 122

Martin Luther King, Jr. on Communication ................................................ 122

E. B. White on rules .................................................................................... 122

Walt Disney on Stakeholders...................................................................... 123

Edward Phelps on Failure ........................................................................... 123

Galileo Galilei on Discovery ........................................................................ 123

George Santayana on Lessons Learned ...................................................... 123

Seneca on Planning .................................................................................... 124

Saint Exupéry on Communication .............................................................. 124

Heinlein on Laziness ................................................................................... 124

Voltaire on Quality ..................................................................................... 124


Joanna Baillie on Change ............................................................................ 125

Oscar Wilde on Lessons Learned ................................................................ 125

Isaac Asimov on Ethics................................................................................ 125

Mark Twain on Ethics ................................................................................. 125

General Lee on Control .............................................................................. 126

H.G. Wells on Change ................................................................................. 126

Aldous Huxley on Lessons Learned ............................................................ 126

Louis V. Gerstner, Jr. on Productivity ......................................................... 126

Benjamin Franklin on Lessons Learned ...................................................... 127

Alan Mulally on Escalation ......................................................................... 127

Vince Lombardi on Leadership ................................................................... 127

Superman on (poor) Communication ......................................................... 127

Mozart on Personal Skills ........................................................................... 128

Theodore von Kármán on Crashing ............................................................ 128

Fred Brooks on Crashing ............................................................................. 128

Dostoevsky on Ethics .................................................................................. 128

Muhammad Ali on Win-Win ....................................................................... 129

Richard Feynman on Teams ....................................................................... 129

Helen Keller on Teams ................................................................................ 129

John Cleese on Teams ................................................................................ 129

Warren Buffett on Available Funds ............................................................ 130

Ernest Hemingway on Ethics ...................................................................... 130

Joseph Conrad on Lessons Learned ............................................................ 130

António Oliveira Salazar on Sponsorship.................................................... 130

Emiliano Zapata on Ethics........................................................................... 131

Laozi on Leadership .................................................................................... 131

George Jessel on Leadership ...................................................................... 131

Miguel de Cervantes on Lessons Learned .................................................. 131

Alan Kay on Leadership .............................................................................. 132

Steve Jobs on Innovation ............................................................................ 132

Zeno of Citium on Communication............................................................. 132

Robert Noyce on Innovation ...................................................................... 132

Anatole France on Planning ........................................................................ 133

ah ha moments yearbook 2011

Documents

luis seabra

seth godin

moments yearbook

project management

people affected

marketing

moments

people