Viewing Posts by sanjay saini
Resource Movement and Management
| 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?
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?
No Project Rework
| 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.
What do you say, is it going to help us?
Treat Me as a Client
| 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.
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?