Tag: communication

Just sharing a thought I came across while reading a book on organizational culture and change management.

Have you ever been in meetings that you came out of and said “That was total BS”? Ever wondered why you couldn’t say that during those meetings instead of after?

Think about your team and organization’s culture. Try to promote an environment of openness and collaboration. It is important that the project manager be the agent that fosters strong team spirit across departments, functional units and geographies. While you may not always have the authority to influence an enterprise wide culture shift, you could start with your project team…

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

Bookmark and Share

Recently, I was working with a PMO Director on improving the quality of her team’s project schedules (built using MS Project). Note that these schedules were fairly basic, so we are not talking about complex cost tracking, WBS linkage and resource leveling. At this point, the goal was just to identify the most critical pieces to capture on a project schedule given this company’s structure and operations. Working in conjunction with other project managers on her team, we identified the following as critical components that even the most basic schedule should reflect:

  1. Have adequate coverage of all activities and milestones critical to the project (see note below regarding what level to track at)
  2. For each activity, clearly capture estimated duration and effort. In this organization getting an accurate indication of effort was quite challenging, so duration was used more often. While this presents some resource management challenges, it was an acceptable approach given the realities of the organization.
  3. It is also important to indicate the dependencies / predecessors so all activities and milestones are clearly linked to each other. This not only makes it easier to administer changes to the plan but also to assess impact of any slippage very quickly.
  4. For all activities identify the resource accountable for the activity’s completion. Dependent on how you do this, and how you set up other linkages in the MS Project file, assigning resources can also help you in estimating costs, in preparing budgets and in resource leveling.

One can do a lot more with MS Project, but we identified these as the most basic requirements given the organization’s and the project team’s needs.

Another important point underlying all this was the level at which to track activities in the project schedule. This depends on the needs of the project – some projects warrant detailed task level tracking, while for others, tracking by deliverables/milestones works just as well. The level at which you track is also a function of which methodology your organization is using as the rules of the game may differ. Although, the gist of it stays the same – what needs to be done, how long will it take, what are the dependencies, who is accountable.

Related posts that you might want to browse through -

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

Bookmark and Share

Recently I attended an event led by a New York University Professor. Here I had the opportunity to listen to two of the best entrepreneurs in NYC (Barry Silbert – Founder and CEO of Second Market, and Marc Cenedella Founder and CEO of The Ladders). A lot of valuable insights came out of this, but one very simple piece of advice really stood out – and the best part is it can help everyone, no matter at what level of the organization.

Have you ever thought that things would improve if only you could change something in your organization but you did not know where or how to get started? Here’s the tip: Think, if you were to get fired, what would your replacement do? Would he or she run things the same way, or would they immediately change something and how would they go about it?

Perhaps this simple question will give you the drive you need to actually execute the change. Go for it – be the change agent your organization needs!

Also, I am planning to attend another exciting event soon! Click here to read more about it…!

Click the image to read about some of the speakers at this upcoming event -

The complete list of speakers at the event -

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

Bookmark and Share

Lately, quite a few non-project-managers and beginning-project-managers have asked me how to break into project management, or how to brush up on the basics of project management. By posting my thoughts through the blog, I thought I’d try to make the answer a little more collaborative. I have highlighted what are some must-have introductory skills, and stated at a high level some intermediate and advanced skills, which can be addressed further in future posts. These are still my work in progress thoughts; experienced project managers out there and beginners who have been through this phase recently, feel free to chime in with your experiences.

As the first step, I suggest understanding how a project traverses through its various stages, i.e. Initiation, Planning, Execution, Monitoring & Control and Closing; know what the goal of each phase is so you can better lead the team towards accomplishing that goal. I stress goal and not all the inputs, outputs and processes described by various methodologies. Regardless of whether you follow Agile, PMBOK, PRINCE or Waterfall approaches, projects follow a few basics: person-A dreams up a project for person-B to execute. Person-B needs to figure out how to organize the resources at his or her disposal to get the work done per person-A’s expectations. This entails reporting the vital stats at periodic intervals, and ensuring there are no loose ends. So read the theory behind what goes into a project’s beginning, middle and end, glean from that theory the practical insights that fit your environment and understand what your role is in facilitating the project through its life cycle.

Leadership, documentation and communication are probably three of the most basic skills needed to run projects successfully. From a documentation perspective, understand what are the needs of the project, of the team and of the sponsors. Some projects and sponsors will expect daily updates, others weekly. Some teams will warrant meeting and following up daily, others work better when left alone. Every project is different. This is where your leadership, communication and documentation intersect to produce what’s in the best interest of the project. At the least, know what goes into a project charter or some form of a project definition document, a status report, an issue log, a risk log and of course a project schedule. Familiarize yourself with the basics of risk identification, activity and resource scheduling, requirements capture and problem solving. Another important basic skill is being able to lead meetings whether they be weekly status calls, kick off meetings, client onsite discussions or steering committee calls. I have been quite surprised by how many PMs don’t know how to lead meetings effectively and efficiently.

IMO, intermediate project management skills focus on more elaborate risk management, issue management, team building, basic budget tracking, scope management, stakeholder management and facilitating proper project closure. Advanced project management includes budget control, detailed risk analysis, cost estimating, tracking project performance metrics through earned value management and other techniques, developing better forecasting skills and honing your project management style using a blend of best practices and methodologies. Check back again in the next few days for more posts on this theme. Btw, thanks to Soma B who unknowingly helped me get started on this series of posts…!

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

Bookmark and Share

Have you ever realized that there is a significant cost associated with meetings and the number of people invited to those meetings?  Consider an average salary of 100K per employee for the 8 employees invited to an hourly meeting.  This equates to $50/hour/person i.e. $400/8-person meeting.  Add to it 2 hours of prep-time for 2 out of the 8 people, leading to approximately $600/8-person meeting.  If this group meets daily for an hour, it equates to $3,000/week or $156,000/year.  Bet that is not what you consider when weighing the pros and cons of setting up meetings (I am sure at times you have good reason not to; some projects warrant frequent meetings).  But I suggest giving those frequent meetings and list of attendees a critical eye just to ensure no one’s time is being wasted.

The message through this illustration is pretty simple – minimize the number of meetings needed, invite only those whose participation is required, and lead meetings with a purpose.  Realize that at times going back n forth on a particular thought, idea, requirement, task or issue may not even be worth everyone’s time.  By this I am not suggesting don’t discuss these items; by all means discuss them but tune yourself to see when the discussion turns into a futile battle of wits and as the PM or meeting facilitator step in when the need arises.  Stress this point to the attendees and refocus the group, trying to lead the discussion to a firm decision either by consensus, compromise or authority.

Off late, I have seen numerous organizations continue to lay off employees even though the work load has increased significantly.  So, as organizations strive to get more out of each employee, and try to boost productivity, it is even more crucial to be judicious with the use of everyone’s time.  Treat it like a scarce commodity and spend it wisely.

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

Bookmark and Share

Not all projects end well, especially in this economy. So once you realize your project is doomed, it is better to bite the bullet, evaluate the project thoroughly and consider calling it off. But doing so is definitely easier said than done!

Reasons to terminate a project prior to scheduled completion include macro-level shifts (changes in business strategy, change in priorities, loss of funding, lack of or shift of resources) or micro-level concerns (schedule delays, cost overruns, extensive resource consumption, unavailable technical capabilities – hardware, skills or software). Irrespective of the reason, it is important to suppress any blame-game once the decision to cancel a project is made. If a project is terminated properly, it can in fact have a positive impact on team morale, budgets, resources, possibly other projects or dependencies and any related future endeavors.

Thus, how you go about canceling a project is essential to seeing any positive impact from it. Some steps to aid cancellation efforts are as follows –

  1. Conduct a thorough review documenting the reasons to continue vs. the reasons to cancel
  2. Perform a gap analysis to better understand and document what is needed to close the project successfully from this point forward
  3. Ensure you review the impact of canceling a project on other projects that depend on it.
    Example:  I once had an application development project that was dependent on a server farm being up and running.  Senior management had approved the project keeping the server farm dependency in mind as the server farm would reduce the effort and investment for this project. However, the server farm project was postponed indefinitely because of budget cuts. But the stakeholders for my project demanded their project’s needs be fulfilled even though the dependent server farm project was dropped. The dependency was lost and forgotten. This resulted in schedule delays, cost overruns, shift in requirements and an operational inconvenience as a smaller one-off instance of the proposed server farm had to be created and maintained for this one project. Had the stakeholders given this project a critical eye or had the team canceling the server farm project clearly communicated the consequences for other projects, planning would have been better and aligning expectations easier.
  4. If there are numerous benefits to continuing a project, but limited funds or resources lead to termination, explore alternatives such as negotiating additional funds/resources/time, re-allocating capital, escalating challenges to the executive-level, and socializing the project’s benefits across other departments to garner more support and credibility.
  5. It is absolutely critical to involve all key stakeholders in the go – no go decision making process
  6. It is equally important to communicate across the organization so any unanticipated consequences can be highlighted quickly
  7. Once the decision is made to terminate the project early, perform proper project closure steps. This entails -
    1. Document the lessons learned clearly
    2. Specify why the project was terminated early
    3. Outline what options/alternatives were explored
    4. Document the latest project status and results achieved
    5. Complete any financial or contractual obligations
    6. Re-allocate resources as necessary
    7. Archive all project material in the company’s knowledge base in case the same or a related project gets resumed in the future

In conclusion, the thought sums it all up, “Canceling a project isn’t a failure, but failing to cancel (properly) is”.

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down)

Bookmark and Share

Occasionally even in your spotless careers, you will come across clients or stakeholders who may be upset with you or your company.  Let me share a personal example.

Early in my career a crucial client meeting was cancelled after a brief discussion between the executives at my company and the executives at a clients company. However, none of the invitees were notified. This was going to be my first meeting with the client (some introduction, right?). There were at least five vice presidents flying in from out of town just to attend the meeting. Guess what happened on the day of the meeting? They all arrived at the meeting location only to find out an hour before the meeting that it had been cancelled.

No one from either company owned up for the miscommunication. But these people were upset. I let the first few hours pass expecting the executives who had caused the miscommunication to sort it out. But no such thing happened. So the first thing I did next morning was pick up the phone and call every single invitee and apologize for the miscommunication. I took the hit then, on my first call with the client. But it was the best thing I did. It established a relationship. The client turned into one of my most successful ventures and a couple vice presidents became life-long friends.

Sometimes the easiest things are the toughest to do. Talking or meeting face-to-face can work miracles. Just do it.

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down)

Bookmark and Share