Wednesday, March 29, 2006

PMBOK way or PRINCE 2 way?


PMBOK (Project Management Body Of Knowledge) is the recognized (de facto) standard of project management knowledge.

In the UK and some other Europe countries, PRINCE2 (Short in Projects IN Control Environment) is the project management methodology of choice.

Many of new project managers are confused when it comes to the methodology whether they should practice PRINCE 2 or PMI Standards. or whether they should invest in learning PRINCE 2 or PMI Standards. Being a PMP I encourage my PMs to use Company wide PMI standards in Project Management as I see there is quite lot of benefits to the business for using PMBOK method. PMs who are familiar in PRINS 2 always try to stay with it. Bur what I say is that anybody could use best out of both..
As I studied, there are many similarities in PRINCE 2 Process compared to PMBOK so the PRINCE2 approach can provide added value to PMBOK knowledge base.

Download Presentation – How to make best out of PMBOK and PRINCE 2

The meaning of "Done"

I face this Done – done situation very frequently… So what sort of workarounds a PM should have with their team members who has their own definitions for “Done”

I found this article today and I couldn’t stop myself from stealing it.. Its that familiar to me :)

Barbara was a programmer on my team responsible for building a utility for our project. This utility displayed a scanned image on a screen, allowed users to define regions on the image, captured the corresponding coordinates, manipulated the regions, and stored the new image in a special format. An adjacent project needed an early version of the utility and we agreed to provide them with a "prototype", which was expected to be functional, ugly, Spartan, and have minimal error checking.

On a Monday, I asked Barbara when the prototype would be finished, and she told me it would be done on Friday. At the end of the week, I went to Barbara and asked, "Are you done with the prototype?"

“I'm done,” she replied.

“Great!” I said, extending my hand. “Give it to me.

“Well…” demurred Barbara sheepishly, “I'm not DONE-done.”

“DONE-done?” I inquired. I'd never heard that one before.

“I built the prototype and tested it using simple test data,” she said, “but I haven't yet integrated the more complex transforms. Integrating those and testing will take another two days.”

“I'll see you Tuesday then,” I said. DONE-done. Ha! What a kidder.

On Tuesday, I stopped by Barbara’s cube. With an almost straight face, I inquired, “Hey Barb, are you … DONE-done?” I couldn't help but chuckle.

“I'm DONE-done,” she beamed. “It works great.”

“Wonderful!” I said, extending my hand. “Give me the disk.”

“Well,” Barbara hesitated, “I'm not DONE-done-done.”

The humor drained from the situation. In my mind, I began hearing Beethoven’s “Fifth Symphony”: DONE-DONE-DONE, DONE. DONE-DONE-DONE, DONE.

I got grumpy. “What do you mean you're not DONE-done-done?”

“Well,” she replied earnestly, “I built the prototype and tested it successfully with the transforms. But I haven't built the readme file that explains the subdirectory structure, or copied the pieces and parts to a diskette. I won't be DONE-done-done until tomorrow.”

I was angry and disappointed. “What time tomorrow?” I grumbled. We agreed that I would stop by at 4:00 p.m. to pick up the diskette.

I went to complain to the senior project manager, Pat, about what an unreliable and equivocating person Barbara was--to whine about Done, DONE-done, and DONE-done-done and explain why I was surprised by the delay. I expected sympathy and strategies for disciplining Barbara, but Pat gently interrupted me and said, “Why are you frustrated with Barbara? You screwed up.”

“Me?” I said. “What did I do?”

“Unclear completion criteria,” Pat said. “If you had been clearer about what ‘done’ meant, you likely would have gotten a clearer answer to your original request for an estimate and probably even a straight answer when you asked about progress.”

“What do you mean?” I asked. “Isn't ‘Done with the prototype’ clear enough?”

“Apparently not,” smiled Pat. “You say she wasn't done Friday--how could you tell?”

“Because if she had been done, she would have been able to provide me with a diskette of the code and information that I needed for the other project to run the utility,” I said, still not getting it.

“Then that’s what you should have asked for when you defined the task,” Pat said. “You might have said, ‘Barbara, I need to send a diskette to the other team so that they can use the prototype. What will it take for you to build and test the utility and put it and any necessary files and instructions on a diskette for me so that I can pass it to them?’ It might not have gotten you what you wanted, but it would have clarified your goals earlier and improved communication.”

Pat had made her point.

Since then, with practice, I've gotten better at defining completion criteria and recognizing when “done” is not clearly specified. I've also discovered that poor communication about completion criteria is often the root cause of disagreements related to task definition, project definition, and whether or not requirements have been satisfied. Take a moment and think about a current task you are doing or someone is doing for you. Now answer these questions:

  • How will you know the task is done?
  • What work products will the task create?
  • What standards apply to the work products to assure they meet requirements?
  • Where will those work products be when the task is complete?

If you and someone else familiar with the task answered those questions independently, would you come up with similar answers? If not, prepare to discuss DONE-done.

Getting good at defining completion criteria isn't magic, though it sometimes seems that way. Pulling a rabbit from a hat is applause-worthy, but asking, “How will we know this is complete?” can save a project.

About the Author Payson Hall is a consulting systems engineer and project manager from Catalysis Group, Inc. in Sacramento. Weekly Column From 03/13/2006

Tuesday, March 14, 2006

Do you have a choice???


In the project office we deal with many types of projects all the time. Local Projects, Overseas projects which are outsourced to us, small projects which won’t go over 2 months and fairly big million $ projects. What ever the project we get., we allocate a PM by using the Project Charter in the initiation. Lately I was thinking.. when we assign a Project to a PM, what will happen if the PM doesn’t like that project. Do you think a PM has a choice??? Can he or she refuse the project? What will be the impact?

Recently I was in Pakistan for a Project Implementation meeting, That specific Project Owner (He is a regional manager of the Company with a wealth of credibility) told the users., if you don’t like this system in your heart, it will never be a success ( Hope I understood it right., he was using their native language most of the time).. Ok that’s for the end users.. How about the PM? …. If you are a PM ,what will happen if you don’t like the project in your heart.. Will that project be a success… ? or can you make it a success..

Any way I thought of asking what industry professionals have faced when they are assigned with a project which they do not want to take over, what happens when they refuse a project…. and do they really have a choice…. So following are some of the facts which I have gathered from the industry professionals around the world. ( through IT technical forums and some online PM friends….. and most of them are PMPs)

Most of the Project Managers who are working for government institutes mentioned that they do not have a choice to make, When ever they are assigned with a project they just have to do it.
Independent Project Mangers and Project Consultants who are working for Projectized type of organizations had a totally different opinion to Government PMs. They claimed that there is always a choice, and you should accept the project only if you like the project and if you are confident about the project.
Generally the Permanent staffs of firms who carry Project Manager Designation gave an opinion which was much similar to the PMs work for government institutes. They said that they have to accept the project and do it. There is a very minimal chance for them to refuse a project., Some of them said , how they are having lengthy discussions and arguments with senior managers about "bad" projects and they complained that the management rarely listen….

My personal view is that, when the project charter is issued, its your baby. You have no choice you should give the birth to the baby. But what you should do is., Understand all the issues clearly including all the politics,( remember there should be a very good reason to turn down an Assignment)Build you case. Make a very professional presentation by including the impact to the project due to the issues (very clearly). At last you should mention the predicted probability for the success based on your experience., and then present it to the board., Don't say that you don't like to do the project or to allocate it to somebody else., But say this is what you see in this project and get them to make the decision;. This is a safe and more professional approach, and more than anything… you have already informed your project board about your concerns even if you are to continue with the project.. But only the experienced PMs should try this.. Others .. Try your best and think of it as a good experience…

Thursday, March 09, 2006

PM - Is it necessary to have technical knowledge ???

Yesterday, while talking to one of my customers , he mentioned that he has followed a Prince 2 course recently. while talking about the topic I realised that he was very strong with his opinion on that a PM doesn't need to have any technical knowledge., But my argument was that PM should be able to get on with techies, understand them, handle politics, manage conflicts and not allow the team to take the PM on a ride. In this case a PM should have a very good understanding of the technical aspects to make the project successful. Any way we paused the discussion as we met for an official meeting,
He is right when I think of PM theories, But in Practical I think when you are in to IT project Management, Guys …No matter whether you handle the biggest project in the world or the smallest ....Don't be lazy to update your technical knowledge….( Im not saying you should have knowledge to design a class diagram right or to code a component, But at least you should know what it is and should be able to understand the complexity of it.

Lately, I participated same type of discussion in a tech forum and the question was whether it's necessary for a PM to be technical ?. Though I wont agree 100% ,I find the following post is very interesting and it talks about most of the concerns we have in this issue. So I just thought to paste it here
There has been an on-going discussion for years as to how much technical background a project manager needs and I suspect it will continue through all of our life times.

First let me say that all project areas believe that they are different and unique. To a certain extent this is true. However, all projects have the same requirements for planning and control to some degree. In softer projects while the structure of good planning and control may not be as rigid as say a construction project, some form of structure is still needed. It becomes critical in large multi-disciplined technology projects, that the PM not only be able to lead the team but also to handle all of the internal political situations that will occur and to be able to sell and handle the corporate change that will occur. They simply cannot become too mired in the technical work.

Having said that my experience across a large number of technology projects in addition to other types tells me several things.

The smaller the project, the more technical background is needed. When a project of any technical type gets beyond a certain size of effort and team size, the more the PM needs to be more generally and business oriented. However, even in a very large project it would be best if the PM has some overview technical knowledge. They need enough to understand the project and to gain the respect of the team. But they do not have to be a highly skilled developer. Think about it, in a large, complex technology project, such as an ERP, we are usually dealing with a number of specialty areas within the technology and the PM cannot be conversant in-depth with them all and still have had time to become a highly skilled people manager.

I propose that what is needed on a larger project is a Technical Lead
working with and for the project manager/project director. the Technical Lead should have a technical architectural background and provide technical oversight of the product during its development. Is this not the same concept that engineering projects have. They will usually have a PM and a project engineer. Both are likely to be engineers of some variety.

The more experienced a PM is in managing projects, the longer they will have been away from any type of hands-on technical work and the less likely they will have in-depth knowledge of the latest tools and languages. This is the role of the Technical Lead. An expansion of the Technical Lead role is into what I call a Product Integrity Manager on the project responsible to the PM. In the expanded role, architecture is still key, but now we add all areas concerning the product, such as change control, documentation and quality.

Bill Bates
P3M Governance Inc.

What do you think? is it nessasary for a PM to be technical ? Developers.. Do you prefer to have a technical PM? feel blog is open for your comments...

Tuesday, March 07, 2006

Learn to understand your team :)

I really dont know how ... I think this is very true.. :)

PROJECTIZED. Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com