Voices on Project Management

by , , , , , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog

RSS

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Vivek Prakash
Christian Bisson
Cyndee Miller
David Wakeman
Jen Skrabak
Mario Trentim
Shobhna Raghupathy
Rex Holmlin
Roberto Toledo
Taralyn Frasqueri-Molina
Wanda Curlee
Joanna Newman
Linda Agyapong
Jess Tayel
Ramiro Rodrigues

Past Contributers:

Jorge Valdés Garciatorres
Hajar Hamid
Dan Goldfischer
Saira Karim
Jim De Piante
Geoff Mattie
sanjay saini
Judy Umlas
Abdiel Ledesma
Michael Hatfield
Deanna Landers
Alfonso Bucero
Kelley Hunsberger
William Krebs
Peter Taylor
Rebecca Braglio
Dmitri Ivanenko PMP ITIL

Recent Posts

The Worst Project Manager I Ever Worked For Was Me

The Next-Gen PMO

Knowledge Is Creative

Project Management Is a People Business

Machine Learning Isn’t Magic

Viewing Posts by sanjay saini

Resource Movement and Management

Categories: Teams

The IT industry is growing—and that means more work for project managers. This is good news, but it also means teams need more people to complete the work.

While recruiting for new talent, project managers have to optimize existing team members as best they can. Some times people may be moved from one project to another, but such changes can make it hard to control the triple constraint of cost, quality and schedule.

Here are my observations on how so many moving parts can impact project delivery:

1. Long-running projects require more time for people to adjust. New team members need about six to eight months to understand the project and its processes.

2. Learning curves vary. An experienced newcomer can still take awhile to become 100 percent productive. Someone just starting out may take more than a year.

3. Getting the highest-quality team members may not be feasible because of the urgency, availability and cost involved. Leverage the strong resources you have.
 
4. Team leaders may have less time to devote to the project. Taking on new project members could force the team leader to focus on daily tracking, resolving team issues and client communication, and less time to work on the project.
 
5. Implement an induction plan. It can take three to four weeks to get a replacement for a team member who resigns or leaves the team. Teams can most effectively deploy new additions by following a regular induction plan to get them up to speed on the project and culture.
 
6. Be flexible. Some people may perform poorly because of the project's complexity, domain, technical knowledge or their interest level. However, that same team member might do well in a different project.
 
7. The estimate for completing a task always differs from the actual effort. This is more severe in long-running projects. The client expects us to have complete knowledge of the system, which is not always true because of internal movement among team members.

8. Teams can work smarter on projects on a fixed bid and when work approval comes in small modules. You can have multiple modules running parallel in different phases, but there will always be some idle time in between.

What do you say?

Posted by sanjay saini on: October 27, 2010 11:05 AM | Permalink | Comments (7)

Risk Simulation

Categories: Risk Management

When we prepare our risk management plan, we believe it will work. The irony is that its effectiveness is only revealed when the risk actually occurs. But have you ever thought of simulating the risk?

Let's start with two very basic risks that can occur with any IT project:

1.    Critical project worker goes on emergency leave
2.    Database server goes down one week before the release

How would you simulate and manage those risks?

In the first scenario, the best option could be just asking the worker to go on leave and see how you manage the work and team. Ask your team members to take leave on alternate schedules so you can measure the impact of each one of them.

In the second situation, ask your team to shut down the server and verify your mitigation plan. It may seem foolish, but this is best way you can determine the effectiveness of your mitigation plan if the risk actually occurs.

What do you say?


Posted by sanjay saini on: July 06, 2010 02:59 PM | Permalink | Comments (13)

No Project Rework

Categories: IT

Generally, an IT project schedule is divided into three phases: 30 percent requirements, 40 percent coding and 30 percent testing. But have you ever noticed that in the coding phase, 60 percent of the effort goes into unplanned bug fixing?

I read somewhere that in the software industry, 90 percent of the tasks take 10 percent of the time, while the other 10 percent take 90 percent of the time due to rework. If as a project manager you can control this rework effort, I am sure that your project will be successful in terms of profit value, customer satisfaction and team motivation.

The project I am currently working on is no different. We had the same rework problem. So based upon data analysis from the last 4 to 5 months, the team came up with a list of preventive actions that will help us in reducing rework.

But I was still looking for something to keep them motivated to avoid rework. I prepared a logo and it was pasted on all desks.

sanjaypost1.png
 

What do you say, is it going to help us?

Posted by sanjay saini on: April 09, 2010 01:24 PM | Permalink | Comments (12)

Treat Me as a Client

Categories: Teams

Dealing with vendors and customers provides a very good example of the peculiarities of human behavior.

As a project manager, you may feel obliged whenever you do anything for your customer. But when it comes to vendors you perhaps put yourself in a position above them and treat them differently.

Take this example:

In the IT industry we have a software engineering process group (SEPG) and software quality assurance group (SQAG) responsible for ensuring the implementation of Capability Maturity Model Integration (CMMI) processes.

Project teams follow the groups' instructions and do whatever is required to clear an audit. Once the organization clears the audit and receives a certification, no one cares about the processes anymore because of the following reasons:

1.    The project team feels unnecessary extra work was pushed on them by the SEPG/SQAG groups and the project team just wanted to be done with it.
2.    The project team feels that they are doing a favor to SEPG/SQAG by implementing the processes rolled out by them, and the SEPG/SQAG feels otherwise.

The best way to keep a sustainable process model is to mentor project teams about the importance of processes to their project. This compare to what we do with our client -- we work as a trusted advisor, providing consultation at each step.

When it comes to an internal project we start treating internal teams as a vendor and ask them to do whatever we need, it doesn't matter if it really adds any value to them. My suggestion SQAG/SEPG teams is that you shall treat the project teams as your client and act as a trusted advisor to them.

This is the only way you can have a sustainable model.
Posted by sanjay saini on: March 12, 2010 04:54 PM | Permalink | Comments (9)

Veering From the Typical Career Path

Categories: Career Help

I recently watched a Hindi movie called 3 Idiots. The moral was to follow your passion--which got me thinking...

In the software industry I've seen examples of technical leads who were promoted to project manager based on the assumption that they'll perform just as well in that role.

But in several of these cases the technical lead has failed in the new position. That's because project management is not about resolving technical issues. It has other parts: resource management, cost management, expectation management, etc.

Companies shouldn't automatically follow the standard growth path for each role, whether it's for a software engineer, senior software engineer, technical lead or project manager. Rather, the path should be decided based upon an individual's capability and interests. A technical lead may be interested in business analyst work or quality-assurance activities instead of the project management role.

Also, as individuals we should have the opportunity to follow our passion and not feel tied to a typical career path.

What do you suggest?
Posted by sanjay saini on: February 03, 2010 04:59 PM | Permalink | Comments (22)
ADVERTISEMENTS

"I am not bound to please thee with my answer."

- William Shakespeare

ADVERTISEMENT

Sponsors