Developing WBS – Effort vs Result

When we start working at a project we are very focused on the process that we follow. For most of IT projects following waterfall model, phases of the project are quite the same. Requirements, Design, Development, System Testing, Acceptance. Even in large projects, we have a time sequence in forms of iterations, phases and within each phase we follow similar patterns.

Estimations are done before hand based on the high level requirements. Which get refined after the details of requirements in first phase are done. But rarely adjusted for actual work. Glen Alleman writes about confusion between effort and results. This is a good article which explains how to move the focus from effort to actual delivery of the project. What he suggests is to create the WBS based on completing a requirement rather than for a phase of the project. One of the advantage of this is that you can actually get a pretty good view of how much work you have really completed. This also helps you work out the dependencies between various features.

My experience with project management suggests use of UML for requirements management. I used Enterprise Architect UML modeling tool for the same some time back. One of the great use of this tool is to be able to model the requirements and be able to map them with actual code components. This gives us a clear traceability between various components and requirements. So when a change in system is required it is much easier to find the impacted areas.

However, I do not agree with some of the exclusion Glen speaks about. Some WBS activities are required to ensure that the product is delivered and the people issues are also well taken care of. We do need to have a holistic view of the product in the early work. We can not break the WBS in set of features before we have addressed some key architectural issues. Also the tooling required for the project is indicated by the design. If the tool has a wider effect on the project, it needs to be considered in the WBS. But apart from these all other points are very valuable for delivering the product.

Thoughts on building technical competency

Often we are faced with challenge of building competency in our organization. These competencies are required at all levels. I will be writing more about IT industry here as I belong to this industry.

Last year, we started an initiative to build competency for our group. I had few ideas about developing competencies in areas of programming and designing. Our managers also were facing these challenges and they had approach to handle this. We clubbed these together and came up with a plan to tackle this.

In the first step, we collected data about our existing competencies. The way to do that was to identify three top most relevant competencies of each of our team members. This also included the project leads and middle management. The focus was on "relevant skills". This meant that if someone had worked extensively on a particular technology some 2-3 years back we may not consider it in top 3. We rated the skills on a level of E1 to E4. Then we also mapped the target levels of each of these competencies in the current project or quarter or half year. Although we collected data from the teams, it was validated by the leads to reflect the usable level of the skills.

Once we did this analysis, we started analyzing the data and listing the E3 onwards level employees. These were called as the champions of the skill area. This list is useful in few key business areas; recruitment, training, responding to proposals, estimation, solving problems of projects, knowledge management.

Alongside we also looked at skill gaps and came with a plan to enhance the skills in those areas. Our main focus last year was on conduction knowledge sharing sessions (KSS). For these KSS we had different types. These were,

  1. 1. Formal training/ presentation on a technology area
  2. 2. Workshops for areas like design
  3. 3. Hands on sessions
  4. 4. Project showcase to demonstrate the in-house skills and build a sense of pride

Today IT industry in India is a hot job destination. Not everyone comes here for the love of job/ industry. Many people also join this industry because of the good salaries. In such scenario, finding people with right attitude towards technology is always a challenge. Some typical trouble makers are people who work within the scope of given work at all times and do not go beyond allocated work. There are other people who want to avoid work, they pretend to be working but come up with some issue or the other at very late stage. The senior members then feel that they better solve the problem themselves.

To some extent this problem can be solved by making people involved and committed to work. This commitment would not come unless we make the job interesting. While this may look like chicken and egg condition, I personally feel that we can crack this by expanding the vision of the team members. Show them what other people at same rank are doing, build a sense of confidence and pride in the work they are doing, show them how technology is changing lives of people, expose them to intricacies of beautiful programs. Even though we may not get 100% conversion, we will definitely create greater interest in the work, resulting in more involvement if not commitment.

This still looks more like an emotion and passion. I am sure most skeptical managers will get back to you and say, "Yeah! This is all fine but then show me how to measure this increase in skill level and how do I show tangible results to top management!" Essentially they are talking about KPI at all levels. There are many ways to show this. The simplest measure is to show how much more business you did with same number of employees. There are lot of ways to estimate size of the software that you produce and there are as many people who will tell you that we can not have a real universal measure of productivity. But this number (Business/Team size) is simplest to demonstrate to management. We measure it a little in detail in form of cost budget and account for the seniority of team members based on designation.There are some more simple metrics which can demonstrate the progress. I mentioned earlier about top 3 skills each individual team member has. We can also track progress in this. Others being industry standard like cost of quality, defect density, quality of peer review etc.

When more and more people get excited about learning new things there is one more challenge. To provide right number and quality of opportunities to these individuals. If the organization has a strong Knowledge Management system, it is an immediate beneficiary. Asking people to blog, create reusable components, frameworks, present technical papers and rewarding all such activities and publicizing the achievements are key drivers.

We started this initiative last year. It slowed down due to various communication issues. For example, many of our team members were working on client network and we did not have a common web site where we can put up all the collected resources. Also the response from team leads was not so enthusiastic. Probably they were more skeptical. This year things have improved on communication front. Whatever we did last year has definitely shown some results and now more and more people are realizing the worth of such exercise. We are putting our bitter experience in a positive mind set and taking this forward. I am sure it will be more rewarding.

TechPM – Technology or Management that is the question

Sometime back, I was a technical guy. Exploring design, architecture, getting hands on experience on new technologies. Today I am a pure Project Manager. For long time I have been in two minds. Whether I should move to project management or not. I always felt that management is not my piece of cake and I am more a techie than a manager.
Some of the questions I wanted to find answers were:
1. Project Management is all about people and technology is all about code, design and so on. Will I have to leave all the technical matters and manage only people, resources?
2. Overall impression is managers do not understand technology. Will I ever become like them? If it happens it is like seeing death of my own self. Will I be comfortable in this new borrowed skin?
3. Any management job is more generic and has longer usability. Specially in India, where all the technical profiles are dominated by young generation, will these people be willing to work with me when I turn 50? Or will they be more comfortable if I am their project manager?
4. In this world everything revolves around money and there is more money in management than technology. If I have to get a technical job at the age of 50 will it pay me the same money when there is a young engineer willing to take up the work at may be 50% of the cost?
5. Does gray hair really matter in technology? Can a younger person be a full replacement for an experienced developer/designer/architect?
6. Will project management be as interesting as development? What keeps the managers going? Where does the job satisfaction in management come from?

As I move on this track I will be exploring to get answers to these questions. If you have any please post comments on this blog.