Sunday, February 27, 2011

Cultural Awareness in Project Presentations

One of the things to think about when preparing a presentation to a large group is: what is their cultural background, and what must I do to make my presentation effective for them?
As you prepare for your presentation, here are a few examples of cultural differences to consider:
  • In some cultures, you can expect many questions from the audience. In others, people may prefer to approach you on an individual basis following the presentation – prepare your presentation accordingly, e.g., whether or not to solicit questions. Is there a particular structure that will work best for your audience, and is there anyone who can advise you in this area?
  • How should your presentation be formatted to be most effective for your audience —- Power Point slides, discussion with notes provided? Certainly, you need to cover the pertinent facts about your project, but are there formats that will have a greater impact on your audience than others?
Read full article:

Creating a Strong Project Schedule

Steve Hart writes for PM Hut:

What does a good project schedule look like? Below are a few questions that help you test your schedule.
  • Are the deliverables and activities broken down to a level that can be estimated and tracked?
  • Has accountability / responsibility been established for deliverables and activities?
  • Can you easily follow the flow of the project work?
  • Do the milestones appear to be reasonable and achievable?
  • Does the resource usage link appropriately to the project budget?
Read full article:

Monday, February 14, 2011

Open space in project management

 Rosana Francescato writes, when most people hear the term “open space,” they think of a green area in or near a city, a place set aside for our enjoyment of nature and to give us a breather from the city’s density. But in the world of project management it’s come to have an entirely new meaning: an open space, in this sense, is a self-organized meeting or event without an initial agenda, and with just on rule, the Law of Mobility and Responsibility (a.k.a. the Law of Two Feet): “If you are not learning or contributing where you are, find a place where you can learn or contribute.” An open space also follows these four principles:
  1. Whoever comes are the right people.
  2. Whatever happens is the only thing that could.
  3. It starts when it starts.
  4. It’s over when it’s over.
Read article:

Brainstorming Project Risks

Risk Management is part and parcel Project Management but the identification and management of project risks are two completely different things. Managing risks needs care and attention for the entire duration of the project.
Identifying risks can be straightforward if started correctly and needs to be well thought out and regularly updated. People are used to brainstorming as an idea generation tool but it is equally useful for identifying potential project risks.
As with any tool it will only work provided it is used correctly so getting the basics right to start with is essential.

Read full article by Paul Slater:


Five Lessons On Truth & Project Failure

Here are the five lessons he provides for project managers to help you bring the truth to light:

1.The truth always comes out and so it is best for you to share it. You will be more favorably regarded by telling the truth rather than denying problems or reaching out for help. It may take a while, but the truth eventually comes out.

2.Reach out for help when you need it. Asking for help is not only responsible, it is also good and appropriate communications and expectations management. Besides, you stand a much better chance of heading off major problems before they grow if you are willing to admit you need help and seek it.

3.When hiring project managers, watch out for those with a spotless record. Be suspicious of those who say 'on time on budget' as if it were a mantra or a secret pass phrase. Ask people about their failures and see what they are willing to share.

4.Harvest every project for the lessons to be learned. A project post-mortem should be conducted for every project, especially those projects that are canceled mid-stream. Also, PMs should maintain a journal of every success, failure, and lesson learned through the execution of the project. Ideally this is something that is done using a few minutes each day or once a week.

5.Expect failure as a requirement for success. If you and the people around you are not failing with regularity, you are not trying hard enough or taking enough risks.

How to Maximize Business Process Reengineering: People, Process, Tools

Business process re-engineering requires project management practitioners to leverage various methodologies such as Lean Six Sigma, PMP and Prince 2 to deliver process efficiency and bottom line savings.
Although these methodologies are used for various purposes in solving for efficiency, there isn’t much focus on the psychological side of project management. My goal is to share key learnings across people, process, and tools that can help you in your business process re-engineering efforts.
In conclusion, project managers are expected to deliver results in shorter timelines with fewer resources. Strong relationships could mean the difference between having someone put your project at the top or bottom of his or her priority list.
Demonstrating relevance is important in today’s economy especially as many companies are engraining “innovation” or “transformation” into their DNA, if they haven’t done so already; therefore, being a great communicator and relationship builder is equally important as being a great technician.
This is the formula I’ve used over the years: 80 percent people + process (relationship/knowledge skills) and 20 percent tools (technical skills). It’s served me well – particularly when implementing new ways to manage projects (e.g., Critical Chain Project Management).
Read Full Article at:
The Project Box | How to Maximize Business Process Reengineering: People, Process, Tools

Sunday, February 13, 2011

Successful Project Review Meetings

The rules for the review, which were developed and distributed beforehand by the organizer, outlined how we would share our ideas, record decisions and deal with issues that arose outside of the agenda. All participants were reminded that on-the-spot decision-making was required.

The purpose and the goal of the review were clarified. All participants had to either agree or disagree with each decision. If there was a disagreement, a discussion took place to clarify the requirements and bridge the gap to reach a final decision.

Having senior decision-makers present allowed us to get through all the points with velocity. We were able to not only review the proposed changes, but also make policy decisions on the spot and discuss relevant details without doubts or assumptions. We recorded anything that needed further work, like the identified gaps, as actions.

WBS and Schedule Network Diagrams: Unsung Heroes of Project Management

If I asked you how to bake a cake, you'd probably tell me to mix the ingredients in a bowl, pour the batter into a tin and bake until golden brown. But that's a deceptively simple answer for what is actually a multi-tiered process.

In project management, you must detail every step needed to get the project done and the precise order in which to complete them.

New project managers may not be used to doing things this way. Work breakdown structures (WBS) and schedule network diagrams can help them in forming a project management plan.

Tuesday, February 8, 2011

Nokia's chief executive to staff: 'we are standing on a burning platform'

Watch out!..Nokia digging deep to make changes to gain market share...I particularly like new Nokia boss Stephen Elop's letter to his staff to explain the dire situation Nokia finds itself in...come to think of it, I did not even realize up to now that the once mobile giant is lagging big time!...That is going to change for sure...Can't wait to see what they come up with!
Nokia's chief executive to staff: 'we are standing on a burning platform' | Technology |

Tuesday, February 1, 2011

My Miserable Life as a Project Manager - PM Hut

I enjoyed this article.

My Miserable Life as a Project Manager - PM Hut

The Insanity of It All!

You’re a project manager, right? You rationalize what you do as normal, right? No offense to the mentally challenged (I hold that we are all mentally challenged, in some way), but consider the definition of crazy and then go look at yourself in the mirror:
  • Full of cracks or flaws - When is the last time you had a project that wasn’t full of cracks or flaws? Isn’t that were it starts? Aren’t cracks in the plan the root cause of most project failures? Or are your projects the exception? Come on now. Nobody’s looking over your shoulder here.
  • Mad, insane - How many times have you preached something over and over again, even become upset about it, just to get the same results? Einstein is quoted as saying the definition of insanity is doing the same thing over and over again and expecting different results. I’m sure he wasn’t referring to you.
  • Infatuated - Oh, the possibilities!! Each project is so alluring at the start, when you don’t see all the monsters hiding behind the bushes. And as reality emerges, you remain steadfast in the belief that this project - your project - will turn heads. It will be your signature achievement. To keep you honest, answer this question truthfully: Which to you spend more time with, your project or your spouse and/or life-partner? Nah, you’re not infatuated with your project.
  • Erratic - We prefer to call them course corrections, right? Do you make course corrections all the time? I’m sure you don’t really have to, even if you do.
  • Obsessed, passionately preoccupied - So, which are you… ambivalent and unsuccessful? or obsessed and passionately preoccupied and successful? I know, this one hurts!
  • Unusual, being out of the ordinary - Isn’t this the very definition of a project?

Mobile Project Management

Geoff Mattie writes, that emerging technologies are changing the dynamics of project team leadership and communication. And the way people have begun using mobile platforms is presenting some challenges. 

Prior to 2006, mobility had a very narrow landscape. Organizations that allowed their work force to have cell phones were usually restricted to one carrier, platform and equipment model. The majority of these phones were used for e-mail and conversations. 

Fast-forward to January 9, 2007 and the introduction of the iPhone, which introduced users to a world of new mobile capabilities.

While users immediately wanted to start using the iPhone at work, IT, security and cost issues made it impossible for many to do so. And to compound the problem, additional devices continued to appear with exciting, productive new features.

Over the last few years, many organizations have caught on and begun to take advantage of these mobile work force capabilities. Such resources have introduced many intriguing possibilities for project managers as well.

But this also means that now project teams are working across multiple platforms with unique requirements and configurations, which can cause performance and compatibility issues.

Some organizations are taking such steps as implementing mobile application program interface (API) layers in their infrastructure, referred to as "Mobile Enterprise Application Platforms" (MEAPs). They allow users to run software shells on their devices and overcome platform differences while providing access to disparate tools.
Other organizations have simply decided to continue to limit their work force to one standard device, choosing to take advantage of some new device capabilities and sacrifice others. Because this challenge is in its infancy, we've yet to see a solution.
Can all of your mobile project team members effectively interact with conflicting mobile platforms? If not, do you have a plan to mitigate this?  How is this situation affecting your project team?