March 2014 Collaborating Project Management for High Performance Business Insight
SYNERGY 02
03
05
Message from Editor-in-chief Synergy in its new avatar. After multiple revisions to the thought process itself of having Synergy.
07
08
All it takes is 7 simple steps to transform from not needed to most needed. By Mona Gupta
Message from the President From national conference to new board members, North India has quite a few updates.
Project Management National Conference 2013 National Level conference hosted at Leela Kempinski, Gurgaon.
07
Managing Talent Gap in Project Management
Using OPM3
Managing small teams—Look beyond process simplification
14
Small teams deliver better than large teams. Can rookie manager do the job? By Vimal Kumar Khanna
Scope creep in construction management
Is the organization really mature? Event in collaboration with IMI, Mr. Raju Rao conducting a workshop.
Some civil projects complete on time but why do majority take ages to finish on time. By Amit Kumar
Infrastructure Project Management
Test Driven Development
Event in collaboration with ERA, Mr. Harish Chawla & Mr. Tanmoy Prasad educating on different horizons.
TDD creates conditions for better product quality before the execution phase. By Amit Kumar
As per PMI Pulse, 79% of the their projects have active project sponsors.
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
22
27
Platinum Sponsor Project Management National Conference 2013
Synergy Mar 2014, Page 1
Foreword Hello Members, It gives great honor to see the rise & expansion of Synergy whose seed was planted by Piyush Govil. I take immense pride on behalf of all the members of PMI-NIC (Project Management Institute—North India Chapter) in expressing my gratitude towards him & the editorial board of Synergy who have worked virtually over the years to help members stay connected and updated with what is happening in the Project Management world.
Prashant Malhotra
Our team’s constant endeavor would be to bring the latest & greatest in this world across various sectors of academia, corporate and the government world. I have always felt that in such a competitive world, Real Leaders grow faster if they could learn from others and in this context I would like to say that we love to receive articles from you all and sincerely wish that they keep pouring in. This would not only help to bring out the writer inside you but it’s one medium where you & us together would showcase your knowledge & learnings to rest of the world. The team now comprises of the below people who have made this editorial come out in a new avatar. Thank you Team and God Bless You !! Abhijit Kumar, PMP
Piyush Govil
Senior Executive Siemens Ltd.
Consultant
Hemant Seigell, PMP,MBA,CPP,ITIL
Pooja Kapoor
Director - Riskpro India Risk Consulting & Advisory
Sr. Engg. Proj. Mgr. (Program Manager) Aricent
Kumar Saurabh, PMP
Prashant Malhotra, PMP, MBA, MCA
Asst. General Manager Samsung Heavy Industries Pvt. Ltd.
Project Manager Aspire Systems
Nirmallya Kar, IPMA Level –D
Shashank Nepalli
Sr. Program Manager STMicroelectronics
Assistant Manager TVS Motors
Before I close out, if something comes to your mind about our editorial whether it is an area of improvement, something is missing or this journal is great, please feel free to share across. We are open to any kind of feedback, be it good or bad as we treat bad news as an opportunity to improve and excel further down the lane. With best regards
Prashant Malhotra Vice President - Communications, PMI North India Chapter
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 2
Letter from the President, PMI North India Chapter Dear Chapter Members, Wish you all a belated Holi, festival of colors. After successful conduct of elections in last quarter of 2013, we are happy to launch the new release of Synergy for Q1-2014 under the team led by Prashant Malhotra, our new VP Communication. This magazine comes to you with a totally new look and feel, although it retains the basic structure and features of the earlier magazine. We are working on certain new initiatives in terms of types of programs being planned to be launched across different locations in North India and you should have seen some events already happening in Q1-2014 and others getting announced in next month. There has been a brief pause in events especially around government participation on account of model code of conduct coming into force on account of impending Lok Sabha elections and we hope to revert back with events in those areas immediately post elections.
Manoj K Gupta
In the meanwhile, feel free to contact us / approach us with your queries and volunteering with the chapter. With best regards Manoj K Gupta President & CEO, PMI North India Chapter
81%
Leadership skills
Technical project management skills
9%
Strategic and business management skills
9% Other
1%
Skills most important for successfully managing highly complex projects.
Source: PMI’s Pulse of the Profession In-Depth Report - Navigating Complexity
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 3
EVENTS @
PMI NIC Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 4
Project Management National Conference India 2013 Bringing Certainty in Uncertain Times In its 10th anniversary, PMI North India Chapter celebrated the annual conference. The event was hosted at a world class facility of Leela Kempinski, Gurgaon. The event brought a fresh breeze of a different kind in the history of PMI India. For the first time; Members had the opportunity to listen to IAS officers in a panel discussion, and answering queries in an open forum. Members had the flexibility to choose between 31 sessions on various topics & knowledge areas. 14 Technical papers were presented by different PMI Members from across the Indian sub-continent on Innovation, Talent, Vision, Diversity & Processes. Members got the insight to Bollywood industry through renowned film maker Mr. Mahesh Bhatt. Early birds had the privilege to participate in the fun-filled session taken by Ms. Valerie Gray on “Are your soft skills too soft?” The event was praised across PMI not only for the work of Directors & Chapter Board but of the volunteers too whose synchronization beyond imagination made it a success. Mr. Raj Kalady who is the Managing Director of PMI India, along with various chapter presidents & members commended the work done by the PMI-NIC Team. Three Cheers for PMI-NIC Board & Volunteer Team —Hip Hip Hurray !!! Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 5
E L E C T I O N S
2
New Board Members New members have been elected to the PMI North India Chapter board by an election nomination committee comprising of three distinguished professionals – Mr. Brij Nandan Yadava, senior vice president - projects, DLF Home Developers; Mr. Neeraj Singhal, PMP, RMP, senior manager - projects, CSC; and Cdr (retd.) Naveen Kataria, PMP, transition and transformation leader - delivery center, IBM India. The committee ensured that the election was fair and transparent. The new board members are Mr. Amit Aggarwal, secretary; Mr. Prashant Malhotra, vice president, communications; Mr. Naveen Singh, vice president, programs; Mr. Vineet Sardana, vice president, membership; and Mr. Saket Bansal, vice president, volunteer management. Office bearers who will continue on the chapter board are Mr. Manoj K. Gupta, president & CEO; Mr. Pritam Gautam, vice president, technology; Mr. Amit Chauhan, chief financial and compliance officer; Ms. Shalini Lamba, vice president, corporate outreach; and Ms. Vanita Ahuja, vice president, government outreach. The chapter board is all set to line up many diverse events for the chapter members with representatives from the corporate world, educational institutes, and the government sector. There will also be more opportunities for volunteering.
Amit Agarwal Secretary
Naveen Singh Vice President — Programs
Prashant Malhotra Vice President — Communications
Saket Bansal Vice President — Volunteer Management
0 1
Vineet Sardana Vice President — Membership
4
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 6
I N D U S T R Y A C A D E M I A I N T E R A C T I O N
Assessing Organizational & Portfolio Management Best Practices using OPM3 – A Practice Approach The half day event was organized along with International Management Institute under the umbrella of Industry Academia Interaction Series of PMI NIC. The interaction with students & professors gave insights on new ideas, research work happening in Colleges & Universities. On the other hand PMI was delighted to educate the brewing talent on techniques & careers in Project Management. Mr. Raju Rao, PMP, SCPM & OPM3 Professional conducted an interesting and interactive workshop for members and students. The event witnessed close to 150 participants. Members were awarded 3 PDUs along with the opportunity to network with other members, professors & students. Event Date : 07 Feb 2014
An evening with PM veterans - Infrastructure Project Management The half day event was organized along with ERA Business School under the umbrella of Industry Academia Interaction Series of PMI NIC. Mr. Harish Chawla, honored by our past Presidents & Prime Ministers, has more than 50 years industry experience and 30 plus years in project & contract management. He started off with the evolution of construction industry. Later he gave an insight on project & contract management along with varied geographical insights. Mr. Tanmoy Prasad, consultant in IT advisory group, Govt. of Haryana presented as how Ministry of Corporate Affairs is transforming itself to meet the ever-changing needs of the competitive world and how companies need to bank upon MCA for the right support structure. Members were awarded 2 PDUs along with the opportunity to network with other members, professors & students. Event Date : 07 Mar 2014
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 7
MANAGING TALENT GAP IN PROJECT MANAGMENT - MONA GUPTA
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 8
We are the second most populous country of the world. We are also a country that believes greatly in accumulating endless degrees/diplomas/certifications/courses, whatever we may call it. It may sound surprising that despite these statistics, there is a huge gap between the skills we need at work vs. what we have. I wonder what’s amiss… It starts with what gets taught in the degree programs/ any other courses. It surely isn’t what we need at work to run projects. Given that, the recruiting teams at companies are forced to choose from what’s available in the job market and getting started. This starts the big journey of compromise. Everyone in the recruiting panel – right from HR to technical interviewers comes with their own set of expectations. A candidate is expected to display an impossible mix of: great attitude, fantastic technical skills, on the job experience, good academics, agree to all terms of employment and above all else, be a very pleasant personality to charm every one of the interviewers. And we have the ‘Best Fit Candidate’.
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 9
fire
N
Then comes the first shock, when work gets assigned. The new joinee can’t deliver. Everyone gets into a meeting – what went wrong? Who was supposed to detect this in the interview but didn’t? Everyone blames everyone else. Next shock – what do we do now? Throw him out? Can’t do so – too soon. He hasn’t failed enough? More analysis – Let’s identify the gap and send him to training. All agree; silently heave a sigh of relief that the problem has been postponed. Now starts the Project Manager’s nightmare. He had estimated a certain delivery time, based on certain manpower numbers. The time goes up , to include training. Job responsibilities of rest of the team have to be shuffled to accommodate this. This is a usual everyday story at almost all small to midsized IT organizations. The scary word is talent gap. No matter what the past experience, academics etc., it just exists and needs to be managed and accounted for.
train him Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
deploy Synergy Mar 2014, Page 10
Basic Points to take care in Project Management-
1 3
ACCEPT THE SITUATION The first thing that needs to be done is to accept it and stop blaming the hiring. Let’s agree, we are all part of the process. Increasing rounds of interview will not fix it. May be we need to change what we assess in the interview. We follow the exact same process every time and expect different results. We rarely try and look for logical ability. We take a memory test instead – firing a volley of questions and expect correct answers. May be we test concepts. That’s good, but can the person apply them? The interviewing itself needs to change.
ESTIMATE AND INVEST IN TRAINING The second step is to know, that no matter how good/ bright the resource, he will not fit in ‘as is’. Project manager has to build in time and effort costs in his estimates to avoid re-work.
TAILOR THE TRAINING Next is to have tailored, relevant training modules for learning. They have to be short and effective. They could be small in-team sessions, some documentation to explain basic architecture etc. Managers mostly tend to assign people to write a code, based on guidelines, without ever explaining where it fits in. Reason – lack of time. Well, maybe we should invest and plan for that time.
TRAINING IS A CONTINUOUS PROCESS Talent gap doesn’t just exist in new people joining. It exists within teams, amongst older team members too. One major lacuna observed is lack of knowledge of what they are doing. No one seems to understand why exactly they are doing what they are told to do. The bigger picture of what the aim of the project is, seems missing. Each one becomes like an individual unit that doesn’t fit into the puzzle. Project managers need to take frequent sessions with the team not just to assign work, but to explain why they are doing so. The overall blue print needs to be disclosed and explained.
2 4
RIGHT PEOPLE AT RIGHT JOB Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 11
5
Another reason for the gap is wrong people for the wrong job. The team composition itself is faulty. Each member has certain ability and fits into a certain role based on technical and other strengths. They are rarely kept in mind while deciding teams. We try and judge each one’s ability on the same scale: How well/fast did he deliver last time? How happy was the client? Well, this time the client is different and the skill needed may be different. Teams always tend to have some brilliant ones and some not so smart people. Surprising as it may sound, we need all types of people in the team. Each one has a strength that needs to be put to use correctly. Brilliant people often get tired with routine based activities. They could be used for more challenging work that excites them and helps the project. The average ones on the other hand work best under direction and supervision. Let’s give them that. I wonder why we try and give challenging work to the ones who are not up for it. We only set the team up for failure. Having said this, it doesn’t mean good ones should be always under high pressure difficult jobs and average people should get it easy. The idea is to put the strengths to work. We should try and minimize the talent gap not increase it.
MAINTAIN WORK BALANCE This also brings to light the fact that assignments have to be balanced. The workload has to be reasonable. It should be challenging enough and yet do-able. Each one should get the opportunity to stretch their limits to learn new things and show their performance.
7
PERFORMANCE MANAGEMENT The last piece is the Performance management. This Performance Management is an annual process at most places and it should achieve two very simple objectives: 1. Assess past performance and give rewards in terms of salary proportionately. 2. Identify areas for improvement/gaps and action items for next year. As simple as these are, sadly both these points are missed. The intent becomes to find flaws of last year, hence reducing the expectation for a big money increase. The second point is completely missed; hence the talent gaps are
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
6
Synergy Mar 2014, Page 12
mostly not identified and therefore not attended to, timely. The only time they come to surface is when the project gets assigned and despite great appraisal ratings, people start failing. So, somewhere the Performance review exercises seem to have lost the essence. It is now long drawn marathon sessions, spread over many months, only to decide how much money to give. All companies have training departments and training calendars. They are mostly generic and meant for up- Project Managers need to dating on new technology trends. become active partners and That is needed and is good, but that take accountability of not isn’t effective in handling the talent gap that exists. Trainings have to be just project deliveries, but custom made to suit the audience.
talent nurturing too.
Right from hiring, to assigning teams, job descriptions, performance reviews and trainings have to be in synchronization. Currently these are not. These are not HR functions alone. These are Business functions. It is not possible to always have all combinations of people in an organization. The trick lies in being able to optimize the talent available and to get the next line ready. Project Managers need to become active partners and take accountability of not just project deliveries, but talent nurturing too; else the talent gap will continue.
Mona, is an experienced Human Resources Management professional with 14+ years experience in various IT firms. She specializes in Strategic HR and has been instrumental in leading organizations through Change Management initiatives in her various assignments .She is a management graduate from IMS ,Ghaziabad. You can reach out to her on LinkedIn Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 13
managing small teams — LOOK BEYOND PROCESS SIMPLIFICATION - VIMAL KUMAR KHANNA Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 14
ABSTRACT Managing large projects/teams is a complex problem. Hence, a significant amount of published work is focused on addressing challenges in managing large projects/teams. However, a number of projects, both in large and small companies, involve managing small teams – like most projects in small companies/startups; pilot projects; rookie managers being initially assigned small projects even in large companies; etc. Although, managing small teams seems easy but actually it presents a number of unique challenges, which are immensely different from challenges in managing large teams. However, most of the published work on managing small teams/projects addresses only the issue of simplifying project management processes. A major issue not being sufficiently addressed is meeting challenges in managing the “human aspect” – deciding manager/team members’ roles based on their strengths; building their skills through training/ mentoring; motivating them; managing their growth aspirations; managing the significant impact of attrition on small teams; etc. This paper explores such challenges in managing small teams and suggests solutions. We consider the cases of managing small teams both in large organizations and in small companies/startups. We present approaches to be adopted both in product development and services projects. The work is based on experiences of managing small teams in global software companies like Novell, Cabletron, QLogic, Atheros, Mindteck, etc.
Pilot projects, even in large companies Rookie managers being initially assigned small projects, etc. It should not be assumed that, unlike managing large teams, managing small teams is easy. Small teams present a number of unique management challenges, which are immensely different from challenges in managing large teams. Most of the published work on managing small projects/teams focuses on need for simplifying management processes. However, simplified processes alone cannot ensure success of projects since it is the team members who finally have to deliver using these processes. Hence, in this paper we would present techniques to successfully lead, train/ mentor, motivate and meet aspirations of the manager/team members of small teams. The paper is based on experiences of managing small teams in leading global software organizations – large companies, small companies/startups, product development and services companies – like Novell, Cabletron, QLogic, Atheros, Mindteck, etc. We are considering maximum team size of eight members, with complete team directly reporting to the manager.
We start by discussing the Related Work. We then discuss major challenges in managing small teams and suggest solutions to address them – experience/ skills/training requirements for managers; scientific method for deciding multiple roles for lightlyloaded managers; techniques to motivate team members despite constraints imposed by small team size; and mitigating significant impact of atKeywords: Small team, small project, pilot project. trition on small teams. INTRODUCTION
RELATED WORK
It has been argued that small teams deliver better It is a known fact that management of large proresults than large teams since they result in greater jects/teams is quite complex and presents many accountability/cohesion/commitment and reduced challenges. Hence, significant amount of published processes/paperwork [1]. work addresses this aspect. However, a number of projects in large/small companies involve managing small teams – Most projects in small companies/startups where overall company team size itself is small
Although, techniques to be followed in managing small projects/teams has received some focus in literature, but most of the published work addresses the issue of simplifying management processes [2-
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 15
7]. All these published works suggest that although managers should not skip planning process and basic documentation requirements, but other management methodologies for large projects can be an overkill for small projects. Hence, managers should simplify project management methodologies/processes/frameworks. Team members in small teams are generally flexible to take up any tasks/roles/ responsibilities since there is never enough manpower for available tasks [2]. We will suggest how managers should effectively utilize this fact to motivate team members.
It is preferred to assign small projects/teams to rookie managers
aging small projects/teams are different from managing large projects. Hence, desired experience levels, management/technical skills and training requirements of managers are different. In large companies, the company has a pool of managers from which it can select the most suitable managers to manage small teams. We will discuss the desired experience/skills of managers to be assigned such roles. However, in small companies/startups, the total manpower in the company itself is small. Hence, all project teams are small, and all managers have to lead small teams. Hence, company does not have the luxury to assign managers with specific skills. For such scenarios, we will suggest training requirements to groom managers to meet the challenges of managing small teams.
Managers of small teams face the following Manager of a small team is generally not suffi- challenges – ciently loaded. Hence, it has been recommend- Managers generally look forward to managing ed that he should also act as a Technical Team large projects. Hence, it is challenging to motiMember or should manage multiple small pro- vate them to take up responsibility of small jects [5]. We extend that work extensively by teams. proposing a range of possible multiple roles to be played by the manager in product develop- Since the project is small, senior engineers are ment and services organizations. We suggest a not interested in joining such teams since the scientific method of assessing “Personality tasks are not challenging as per their experiType” of the manager to decide his additional ence. Hence, managers have to lead teams of role. young engineers. The managers need to groom these young inexperienced teams on project Methods for a manager to motivate small team requirements/technologies. members are presented in [6], suggesting the manager to lead by influence and not by auIn large projects/teams (product development/ thority. We will describe many more actions services projects), there are multiple senior perthat a manager should take to motivate team sonnel handling various responsibilities – Promembers. ject Manager/Program Manager/Project Leads, etc. Since a small project is being managed by DESIRED EXPERIENCE, SKILLS AND a manager with a young team, the manager is TRAINING REQUIREMENTS FOR MAN- generally the sole senior person knowledgeable AGERS about the activity. Hence, the manager has to have expertise to act as the sole external interThe characteristics and requirements of manFeedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 16
face for the product/project.
teams allow them time to jump technically quite deep in the project/product, an opportunity not provided in large projects where they are loaded with a huge set of responsibilities/tasks. Hence, technically-inclined managers enjoy their tasks and remain motivated. If the managers are not technically strong then they should get trained/mentored in the technical domain of the project. A moderate level of technical skill is also acceptable since the manager can have an Architect in the team to handle complex technical tasks.
It is generally assumed that since the manager is not handling the challenges of leading large teams, he need not be highly expert in tackling interpersonal conflicts. Hence, interpersonal trainings for managers are generally ignored. However, on the contrary, this skill in managers of small teams is much more critical than for the managers of large teams. Assuming a team of only five engineers, even if two team members are having a conflict then 40% of the project gets impacted. The project is bound to be doomed. In comparison, a conflict There are other reasons for the manager to have among two team members in a large project has a moderate to high technical skill. Being the sole very low impact. senior person in the team, he is the sole interface to the external world for the product/project. Hence We suggest the following solutions to address these he must be able to technically understand the challenges – product/project, present it to external entities, understand their inputs and incorporate them in the It is preferred to assign small projects/teams to product/project. rookie managers – i.e., managers who are recently promoted from Project Leads/Senior Engineers Further, small teams have low experience team roles (say, 7-9 years experience). Since they are members. A technically strong manager can quicklearning new management techniques, they would ly train/groom young engineers on the project rebe excited and motivated on their role despite the quirements. Further, the impact of attrition within team being small. a small team is much higher than on large teams. A technically strong manager will have a deep underHowever, some small projects are complex and standing of the project requirements/design/ rookie managers cannot manage them. Further, in technologies, and hence can ensure that the impact small organizations/startups all managers need to is minimized and new replacement joinees can be handle projects with small teams, including senior quickly brought up to speed on the project. managers. Hence, a major challenge is to keep them motivated even when handling such responsi- As discussed earlier, unique management skills are bilities. We suggest such organizations to hire man- required for managing small teams. Hence, we suggest the manager to at least undergo Covey’s “Seven Habits Training”. He should also get extensively trained on skills like – managing interpersonal conflicts; training/mentoring young team members; motivating team members; etc.
A technically strong manager can quickly train/ groom young engineers on the project requirements.
MULTIPLE ROLES FOR MANAGERS Managers leading small teams have low workload. This low workload can sometimes demotivate the managers, especially if they are senior experienced managers. Low workload also results in managers agers who are technically-inclined. Managing small having more time on hand, which leads to their miFeedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 17
E X T R A V E R S I
cromanaging the team members and making them unhappy. Hence, we suggest utilizing the additional time of these managers judiciously. As discussed in previous section, these managers generally have good knowledge of technical/business domains of the product/project. Hence, organizations should utilize their knowledge and assign them a dual role related to the product/project being managed by them.
play additional role of being a “Business Development Manager” in these domains. He can approach other customers having similar services projects requirements, present company’s expertise in the specified technology/business domains, convince the customers and win new services projects.
Architect/SME: for the services project. The decision on choice of the additional role for the manager depends both on his technical exWe suggest one among the following additional pertise and his psychological personality. We roles in product and services companies, resuggest that manager should undergo a scienspectively – tific “Personality Type” assessment using Myers-Briggs Type Indicator (MBTI) assessment PRODUCT COMPANY [8-10]. Product Management: The manager can play a product management role – study competing MBTI measures psychological preferences in products, gather new requirements from cushow people perceive the world and make decitomers and suggest new features to the prodsions. MBTI defines “Personality Types” as a uct. combination of the following attitudes/ psychological functions – Customized Solutions: Customers sometimes look for an end-to-end managed solution inAttitudes: Extraversion/Introversion stead of adopting only the core product. The core product needs to integrate with customExtraverts (E) are action-oriented, operating ers’ existing systems/software and needs to of- in external world of behavior/action/people/ fer a range of additional features specific to things. their requirements. The manager can play the role of gathering inputs from key customers Introverts (I) are thought-oriented, operating and suggesting customized solutions for them, in internal world of ideas/reflection. which evolve into new services projects. Perceiving (information-gathering) Functions: Architect/SME: Usually projects have dedicat- Sensing/Intuition ed Architects/Subject Matter Experts (SME). However, in the absence of such a technical Sensing (S) individuals trust information that expert, this role can be assigned to the manag- is present/tangible/concrete. For them, the er of the project. This option should be exermeaning is in data. cised when the manager is technically very strong and can balance his technical tasks with Intuitive (N) individuals trust information management responsibilities. that is abstract/theoretical. For them, the meaning is in underlying theory/principles that are manifested in the data. SERVICE COMPANY Business Development: The manager has good Judging (decision-making) Functions: Thinkexpertise in the technology/business domains ing/Feeling of the services projects he is managing. He can
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
I N T R O V E R S I
Synergy Mar 2014, Page 18
These are decision-making functions based on data To start with, the manager should be careful in sereceived from above information-gathering funclecting the team members. In a small team, the tions. manager handles most of the important functions with limited scope of delegating any major funcThinking (T) individuals decide from a detached tion to another senior team member. Hence, if the standpoint, measuring the decision by what seems organization has very senior engineers/project reasonable/logical/causal/consistent, and matching leads, who aspire to grow fast to management a given set of rules. roles, then they should not be included in small teams. They fit better into large teams where they Feeling (F) individuals decide by associating/ can get the responsibility of leading a subset of empathizing with the situation, weighing the situa- team for specific project modules. A small team tion to achieve the greatest harmony/consensus/fit, should ideally consist of either young engineers or considering the needs of the people involved. technically-inclined senior engineers, who aspire to grow in technical ladder (not management ladder). Judging versus Perception preference The major benefits for members of small team are Judging (J) individuals show the world their pref- that they generally have complete view of the erence for judging function. Perceiving (P) show product/project and have direct interfaces with their preferred perceiving function. the Project Manager, Product Manager, internal/ Let us consider example of a technically external customers, etc. In contrast, engineers in “Moderate” manager with Personality Type large teams have a narrow focus since they are ex“ESTJ”. Since he has only moderate technical posed only to their specific project module, usually skill, he cannot play the Architect role and should interact only with their immediate Project Lead, take up one of the other described roles. Since he is have limited interactions with the overall Project an “Extrovert” (E), he likes interacting with exter- Manager and have minimal interfaces with external world/people. Hence, he can be considered for a nal entities. “Product Manager” role since he needs to interact with customers to understand their requirements. The managers of small teams should utilize these His Sensing (S) function allows him to gather tan- facts to motivate their team members through folgible data about features/capabilities of competing lowing means – products. His Thinking (T) preference, which is also his dominant Judging (J) function, allows him The Project Manager is responsible for interacting to logically evaluate customers’ inputs and compet- with external entities, like Product Manager and ing products’ feature-set and decide right product internal/external customers. In case of large profeatures. jects, the manager generally includes the Project Leads of various modules in such meetings since MOTIVATING TEAM MEMBERS they can share details of progress on feature-set of Since the team size is small, its members have lim- modules being managed by them. However, in ited challenges and growth opportunities. Hence, small teams, the manager does not have the luxuthey could lack motivation. Hence, an important ry of having Project Leads. The manager should challenge for managers of small teams, as comutilize this fact to increase exposure of young team pared to managers of large teams, is to keep the members. The knowledge of the complete project team motivated despite these constraints. is distributed among all team members. Hence, the manager should include the concerned team We suggest the following techniques to motivate members in meetings with these external entities the team – when the feature-set/module being handled by them needs to be discussed. Hence, young team
P E R C E P T I O N
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
P R E F E R E N C E
Synergy Mar 2014, Page 19
members get opportunities of interacting with Product Manager to understand how product/ project strategies and feature-set are decided.
sometimes have very strict policies on percentage of team members who can be rated high, since they want to maintain a “Bell-Curve” in the organization for performance ratings. E.g., the company may have a policy that only 15% team members can be rated at level “A”. In large teams, this aspect is not an issue since the possible number of members who can reach this high rating is limited and can fit within this limit. E.g., for a 30-member team, five members can be rated “A”, which is a reasonable number. However, if the team size itself is, say, only 6 then maximum one member can be rated “A”, which is very constraining for the manager, especially if he has more than one starperformer. Hence, the bell-curve has to be artificially applied to small teams, leading to employee demotivation.
THINKFEELING
They get opportunities to interact with customers to understand their requirements/issues and learn how to convert these inputs into features. This exposure gives them a broader perspective, trains them on tasks that usually engineers of their experience do not handle and prepares them for future major responsibilities. Hence, engineers are excited about their work.
The manager should regularly interact with the team members and share with them the complete understanding of the product/project and show how it fits in overall company goals. This systemic view of the product/project and understanding of the criticality of their own The solution is for the manager to convince the role to the success of the overall activity, moti- organization not to force bell-curve on individvates team members to perform. ual small teams but to spread it across multiple small teams. Say, create a pool of five small The Architect in the team should be motivated teams of 6-members each, to create a virtual by informing him that he is developing comteam of 30 members. In Performance Rating plete product/project architecture, instead of Meetings, the managers of these teams can prearchitecting a single module for a large project. sent their cases to “Engineering Head” to seHence, he is handling major/complex/ lect the top 5 members among these teams for challenging task that prepares him for future “A” rating. Since Engineering Head is aware of responsibilities. relative performance of each team, he can judge which teams have higher number of high In small teams there is never enough manpow- -performers, and thus more members of those er for the available tasks. Hence, each team teams can be rated “A”. member should be assigned multiple tasks that will make him learn/apply multiple technolo- MITIGATING ATTRITION IMPACT gies/techniques, an opportunity that a small The impact of attrition on small teams/projects module in large project may not provide. is much higher than on large projects. E.g., Hence, the challenges being offered by the pro- even if a single member leaves a 4-member ject keep him motivated. team, the project loses 25% of its manpower! The impact on his module and on overall proSince team is small, the growth opportunities ject can be drastic. for team members are limited. Companies Hence, the manager must apply techniques to
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 20
work, March. pp. 36-39. prevent attrition and mitigate its impact, if it oc3. Kroll, K. (2007). Small Projects, Big Results. PM Netcurs. The motivational techniques described in the work, July. pp. 30-33. last section can control attrition to a large extent. 4. Larson, R., & Larson, E. (2004). The Critical Steps to Manager can additionally apply the following techManaging Small Projects. PMI Global Congress – Praniques – gue. 5.
As a first step, the manager should avoid choosing team members with the same last name! Say, if the team has a husband-wife combination then there is a very high possibility that both will leave together, in case one leaves the organization to move outside the city. Insist on team members holding regular knowledge sharing sessions within the team about their modules. Hence, if one member leaves then others are still knowledgeable about his work, which reduces the impact of attrition. Manager should also formally groom backups for team members. In large teams, the managers have the luxury of having additional resources who are earmarked as backups. Unfortunately, small teams are always constrained of resources and hence cannot plan a backup within the team. The manager of small team should work in tandem with a manager of a large team in the organization, to earmark an additional resource within that large team as a backup for his team. That engineer should be regularly involved in the project functions of the small team to be aware of the tasks being performed by other members. E.g., he can act as project design/ code/test-cases reviewer. Hence, if a member of small team leaves then he is ready to join the team and takeover the leaving member’s module fast. However, if the company itself is small/startup then the manager cannot fallback on another large team for creating backups. In such a case, the company should offload some project tasks to a services company. Hence, the services company’s resource can act as a backup for the small team. REFERENCES 1. 2.
Baker, B. (2009). In praise of small teams. PM Network, March. Ladika, S. (2008). Bigger isn’t always Better. PM Net-
Fuezery, G. (1998). Managing Small Projects. PM Network, July. 6. Rowe, S. (2007). Managing and Leading Small Projects. PMI Global Congress – Atlanta. 7. Rincon, I. (2006). Mini and Micro projects: Are the principles of project management appropriate for managing small companies or small projects? PMI Global Congress – Madrid. 8. Myers, I., & Myers P. (1995), Gifts differing: Understanding personality type. Davies-Black Publishing. 9. Jung, C. (1971). "Psychological Types". Collected Works of C.G. Jung, Volume 6. Princeton University Press. 10. Damle, P. (2010). Application of select tools of psychology for effective project management. PMI India Conference 2010, Mumbai, India.
Vimal Kumar Khanna is Founder and Managing Director of “mCalibre Technologies”, a software product company. He has over 28 years industry experience and has won multiple international honors. He is listed in “Marquis Who’s Who in the World”. He is also among 30 select experts in the world on “IEEE Communications” (pub. New York) Editorial Board (invited honorary position). His multiple independentlywritten papers have been published in leading international journals/conferences, including PMI North America, APAC & EMEA Global Congresses; multiple “PMI Asia Pacific e-Link” issues; PMI India Conferences 2010, 2011 & 2012. He has been interviewed in “PM Network” magazine.
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 21
SCOPE CREEP in CONSTRUCTION MANAGEMENT
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 22
INDIA is evolving as developing country and a promising power among South Asian Countries. We are striding in every field and writing success stories. Growing economy, gross domestic product, increased per capita income, purchasing power, population etc. require various infrastructure to fulfill the demand. Infrastructure encompasses everything including power, energy, roads, rail, metro, water supply, waste water management, township, commercial centers and many more. Construction is the core of delivering any project whether of small quantum running for few months or major construction works running for number of years to deliver the project. Mega Projects including Thermal Power Projects, Gas Power Projects, Hydro Power Projects, Solar Power Projects, Nuclear Power Projects, Inland Water Ways, Petro-Chemical Refineries, Express Highways, Tunnel Projects, Rail & Metro Projects and Production Units are being developed. Final product/deliverable of any project and processes involved for delivery of that product/ deliverable are vital aspects.
Project has to deliver within the imparted time and budget as per the defined Scope. Baselines are derived for all these components that are integral parts of Project Management Plan and the same are used to track and control the project in different phases. All aspects are equally important and require due consideration for Project Management and can never be dealt in isolation; however "Project Scope" is something that governs each and every factor of project management. PROJECT SCOPE —WHAT As per PMBOK fifth edition, "The work performed to deliver a product, service or result with the specified features and functions." Let’s simplify. Project Scope defines Project Parameters. It defines what project is meant for and how to achieve the project deliverable within the boundaries as described in the scope itself. What these boundaries are/may be: 1. Time 2. Budget 3. Characteristics of deliverable. 4. Technical parameters of various activities within project. 5. Statutory requirements. 6. Methodologies specific to projects.
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
7. What is to be done and what is not to be done. PROJECT SCOPE —HOW Let us not indulge in-depth in the technical terminologies of PMBOK, however I would like to navigate around those with emphasis on the practical applications. Requirements are collected from all stakeholders to cater to their needs at various stages and phases of project. There may be a number of work packages and contracts involved during project depending upon the complexity of the project. Output of one package serves as an input for the subsequent package. The project scope shall be described in detail; identifying and mentioning all deliverables, assumptions and constraints if any. It shall include complete information for the project team and agency so that desired product, service or result can be produced on time and sufficient budget. The "Project Scope" is defined in initial stage of Project Management and agreed upon by the all stakeholders.
SCOPE CREEP Construction Project Management is a very difficult to execute within the parameters as defined in the "Project Scope". It is more complex where it has
Synergy Mar 2014, Page 23
direct interfaces with the public, environment, geology etc.
Let us explore the concise definition of scope creep from PMBOK. "The uncontrolled expansion to product or project scope without adjustments to time, cost and resources." Scope creep is also know as continuous growth in the scope, focus creep, function creep, requirement creep, kitchen sink syndrome and feature creep. In manufacturing industry "Scope Creep" may be seen as increase in scope due to addition of new features or functions to its already approved product design. If project delivers services; addition of some more services may increase the scope. Whereas in construction pro-
jects the deliverable may be a complete commodity as express highways, power projects etc.
However the phase and process of construction may have interactions with unforeseen events and incidents. Most of the times these events and incidents result in time and cost overrun. I would like to cite an example of Hydro Power Project. Suppose an hydro power project's scope statement is "Construction of dam, spillway, power house, switch yard, power intake for 6x400MW hydro power project at Yamuna river, Uttaranchal." The above scope statement is very concise and indicates construction of various components to deliver a complete dam project that can produce 6x400MW power as its final end deliverable/product.
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
The detailed scope of this hydro project is mentioned in scope of work. The construction of hydro project involves land acquisition, resettlement & rehabilitation, corporate social responsibility, township for employees etc. associated with the Construction of Dam Components. All above mentioned works are integral for completion of the hydro project; requires due and timely consideration. Most of these works are dependent and some are independent of each other. All of these works are divided in more smaller and manageable works/packages with assigned budget, time and resources to complete them. Each one of them have their own Scope in contributing the "Project Scope Statement" as defined above. These packages may be executed in house or awarded to agencies through contracts. During execution these packages have interfaces with each other, ones completion or incompletion affects start and/or completion of the other packages/contracts. Now suppose Rs. 400 Crore is assigned in total project's budget for 'Land Acquisition' for 1000 Acres of land coming in submergence to be acquired within 2 years of project start as envisaged in early stage of Project Charter and Project Management Plan; hence scope pertaining to land acquisition
Synergy Mar 2014, Page 24
defined. However during actual land acquisition it is quantified that the land required is 1400 Acres in comparison to envisaged 1000 Acres. Further Project Affected People (PAP) demands for increase of rate of land for per unit of acquisition. They agitate and strikes for the same and in the interest of the management negotiates for increased rate of land for per unit of acquisition. It vividly increases scope of work from 1000 acres to 1400 acres and further increase of rates. Further due to these agitation and settlement process, land acquisition work completes in 3 years instead of 2 years. This is an example of scope creep that affects time and cost. Suppose Rs. 1000 crore is assigned in total project's budget for 'Resettlement & Rehabilitation' for construction of 250 number of plots, 200 homes, rehabilitation of 50 number of temples & shrines, 1 number of shelter for animals etc. as envisaged in early stage of Project Charter and Project Management Plan to completed in 4 years; hence scope pertaining to Resettlement & Rehabilitation defined. However during actual R&R construction of 325 number of plots, 300 homes, rehabilitation of 60 number of temples & shrines, 4 number of shelters for animals is done and additional access roads of 4 Km for resettlement colonies are constructed as demanded by the local villagers which was not envisaged in scope of the R&R
work. This R&R work is completed in 7 years instead of 4 years. This is an example of scope creep that affects time and cost. Now it comes to construction of components of hydro project i.e. dam, spillway, power house, switch yard, power intake. It is decided by management to award these components as individual packages/ contracts based on International Competitive Bidding to invite proposals from technical and commercially sound agencies in these respective areas. Allocated budget for dam package is Rs. 1800 crore with scheduled completion period of 5 years. However during construction some technical problems encountered due to geological surprises as collapse massive side slopes because of earthquakes that requires slope stabilization with additional cost of Rs. 70 crores, sudden gush water encountered during mid way of tunnel construction that requires to realign tunnel from new route and additional cost of Rs. 400 crore. Apart from this technical consultant suggests for chemical grouting for seepage control of drainage galleries that is an costly option but needed with additional cost of Rs. 100 crore. Total cost incurred for construction of dam package is Rs. 2370 crores and actual completion period is 7 years. This may also be cited as scope creep that demands for additional time and cost.
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Rs. 1000 crore allocated for Corporate Social Responsibility (CSR) to develop amenities and enhance infrastructure facilities in nearby towns as desired by the local administration as schools, hospitals, pedestrian paths, donations for physically challenged children and many others. However local administration requests for some additional amenities to be developed as bus stops, play grounds etc. that incurs additional Rs. 150 crores. When the entire project construction is in middle of its scheduled completion a directive is given by state government to increase height of dam by 1.5 meters. It increases the area under submergence, project affected people, further warrants for additional Land Acquisition, Resettlement & Rehabilitation, Design of all Dam Components is reviewed if require any change and certainly it demands of another additional investment of Rs. 1000 Crore. Summing up all these types of cases and incidents the above hydro projects takes about Rs. 8000 crores instead of total allocated budget of Rs. 5000 crores with actual completion period of 12 years instead of 8 years as envisaged in baselines. There exists a defined "Change Control Management" to track the progress and status of project execution against baselines and baselines are revised as per
Synergy Mar 2014, Page 25
the validated changes and subsequent incorporation. In above example of mega project construction all unforeseen incidents, events and changes can never be envisaged in advance as have dynamic interaction with local public, administration, act of God and geological surprises. Managers at all kinds of construction-related firms encounter this problem every time a client incrementally expands on or changes the original scheme. And as firms begin to accept changes to the original scope of work without taking the proper measures to control scope creep, workload can double or triple. Sometimes increase in Scope may jolt the complete project and dislodge it from Cost Benefit Ratio based on that the project was approved. Factors beyond control of the Project Management may be blamed for the scope creep resulting Cost and Time overrun. At the same time we shall not avoid refining our Project Management skills by considering thorough and precise information, facts and statistics to derive pragmatic Baselines and Project Management Plan (PMP). There are some common causes of scope creep in any industry as detailed below: POOR REQUIREMENTS ANALYSIS
Stakeholders don’t always know what they want and can only provide a vague idea. The "I’ll know it when I see it" syndrome. Lack of proper initial identification of what is required to bring about the project objectives. NOT INVOLVING EARLY ENOUGH
THE
USERS
Thinking you know what the users want or need is a serious mistake. It is important to involve them in both the requirements analysis and design phases. UNDERESTIMATING THE COMPLEXITY OF THE PROJECT
Many projects run into problems because they are new in an industry and have never been done before. Nobody knows what to expect, there are no lessons learned and no one to ask. LACK OF CHANGE CONTROL
You can expect there to be a degree of scope creep in most projects, therefore it is important to design a process to manage these changes. A simple process of document, consider, approve and resource can be implemented. GOLD PLATING
This term is given to the practice of exceeding the scope of a project in the belief that value is being added. These changes inevitably consume time and
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
budget and are not guaranteed to increase customer satisfaction. Our pace of project construction has been increasing enormously since past 10-15 years. We are still learning to join all open ends of Project Management to avoid and reduce any risk that may plague our projects. We need to learn from our previous and present Project Management experiences and incorporate these experiences and lessons in our future projects to avoid negative incidents warranting scope creep, time and cost overrun. Amit Kumar is a certified Project Management Professional (PMP®) and currently associated with NTPC Limited as Manager (Civil). He has more than ten years of experience in Project Management, Contract Management and Construction Management of Hydro Power Project, Infrastructure and Township development. He has experience in different facets of construction packages as Proposals, Estimation, Technical & Administrative Approvals, Pre Award Tender Activities, Post Award Contract Execution & Administration, Bills, Claims, Analysis of Rates, Change Orders, Contract Closing etc. He is a graduate in Civil Engineering from JNV University, Jodhpur and PGDBA in Marketing Management. He can be reached on Linked In.
Synergy Mar 2014, Page 26
- VIVEK K GUPTA Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 27
This case study shares how Rational Requirements Composer (RRC), Rational Quality Manager (RQM) and Rational Team Concert (RTC) can be leveraged to implement Test Driven Development (TDD) as the project process for small development teams. The traditional TDD is tailored to meet the project process requirements. RRC, RQM and RTC are customized to support the TDD planning process. By facilitating collaboration, TDD creates conditions for better product quality before the execution phase. Since TDD as a project process deviates from normal project process, it is not a straightforward exercise to put it in practice. However using Rational Collaboration Lifecycle Management (CLM) suite tools (RRC, RQM, RTC), the same can be implemented with much ease.
CHALLENGES The primary challenge was to scale the traditional Test Driven Development practice as the project process primarily from project planning and tracking perspective as it differs from the traditional agile planning. Other challenge was the automation of the project process which was overcome by implementing Rational CLM suite in a slight different manner.
“The proper use of comments is to compensate for our failure to express our self in code.” – Uncle Bob Martin We started with TDD process implementation as part of the development lifecycle and also performed agile monthly sprints. In the sprint reflections, we discussed the process improvements and implemented them by the next sprint. Pretty soon, the process got stabilized and we now have a fully functional TDD process implementation in the project.
EXPERIENCE Test-driven development (TDD) is a software development process that requires the developer to write an (initially failing) automated test case for the desired functionality, then add the minimum
code required to pass the test case and finally refactor the code and ensure the automated tests still pass. We defined our TDD based project process workflow using Rational solutions tools as described: 1. All the project requirements were captured in Rational Requirements Manager. 2. Testers developed test cases for these requirements in Rational Quality Manager and maintained requirements traceability using the “Requirements Links” feature of RQM. 3. Test cases were planned for a milestone and assigned to developers. 4. Developers captured all implementation details and work artifacts in RTC work items. These work items were linked to the test cases via the “Development Items” section for traceability links. 5. Developers did the needful to ensure test cases passed. They also developed test automation packages to test for automated regression. Test case results were stored in RQM automatically. A test case was marked as complete upon its successful execution in RQM. This indicated the completion of the implementation of requirements and the test case was included in the regression suite. The project used agile scrum process for planning and tracking wherein incomplete test cases were treated as backlog and were prioritized for each sprint. Ratio of completed test cases v/s incomplete ones was used as a metric to understand quantum of total work done and pending work. We shall now describe the project process tailored to drive TDD from planning to delivery : PLANNING Milestone Planning: Planning tasks are of two kinds – requirements planning and test cases planning. Requirements Planning: One plans the require-
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 28
ments that needs to be detailed and for which the test cases needs to be written. Test Case Planning: One identifies test cases to be implemented for the planned requirements. Test Execution Records (TER) are created under 'backlog' milestone in 'Incomplete' state for the test cases written as an outcome of the requirements planning. For the test cases that are planned to be completed in this sprint, the test execution records are moved from 'backlog' to this sprint.
created. These test cases are then visible on the project dashboard with status as "Incomplete". This is an indicator that these test cases are to be implemented. Developers link the test cases (through RQM) with the implementation development work item (through RTC) using “Development Items" Link. Developer then implements the test cases for that item in the automation framework.
EXECUTION
Developer will execute the test case which will fail initially as no code is implemented and finally it should pass when the functionality is implemented.
Test Case Development Process: This process defines how code is developed driven by a test written for a requirement.
This completes the test and code development for the requirement.
For every requirement, one or more test suites are created in Rational Quality Manager.
Test Case Execution Process: Test cases are executed at two levels and status tracked via the test execution record.
In the Test suite design, all possible test scenarios are identified ensuring a thorough coverage of the requirements. Each scenario contains sufficient details about the test case intent and how it should be tested (in brief) so that the same can be elaborated in the test case. Post completion of the test suite design, test suite is formally reviewed by peers to ensure that identified test cases cover the requirements in detail. Post review, the test cases are created. Each test case is linked with the requirement being tested. For each test case proper priority and category are identified to help decide the execution of the test case. Priority determines when the test case would get executed as described in the next section “Test case Execution Process”, while category decides if the test case would be automated or manual. For the test cases which can be automated, required skeleton in the automation framework is
Development Stage: For a newly created and reviewed test case in the development test plan, an execution record is created under "Backlog" milestone in "Incomplete" state. This is the first step in TDD wherein we have a failing test case initially. During milestone planning, developer will change the milestone for this execution record to the milestone in which this test case is intended to be developed. After the successful execution of this test case, developer changes the state of this test case to "Approved" which marks completion of the development cycle. This adds the test case into regression cycle automatically. This is the sec-
“One bad programmer can easily create two new jobs a year.” – David Parnas ond step in TDD where code gets added to pass the test case. To ensure that this new change will not cause any regression in the existing functionality, all Test cases of P1 Priority in Regression Test
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 29
plan must be executed. Only after successful execution of developer Regression, a change set would be delivered to the stream. This is the final step of TDD where any further changes to the code (new implementation or refactoring of existing code) should ensure the automated tests always pass. Integration Build Testing: This is done on a regular basis depending upon the project need and at least once a week. This comprises of the following:
On a weekly basis, all the "Approved" and "Automated" test cases are executed through automation framework. Usually this includes the High and Medium Priority Test cases.
Low Priority tests are the ones which are not automated due to time taken for automation of such test cases. These are reviewed at major release milestone and planned for manual execution. These tests however need to be executed at least once after its addition in the regression test plan.
For any failing test case a defect is created against the owner of the failing 'Test Result' which marks this test case as blocked. Any defects coming from regression are taken up at highest priority by developers. There is no milestone set for regression testing, and all the Test Execution records belong to a
“Daddy, how is software made?” “Well, when a programmer loves an idea very much they stay up all night and then push to github the next day.” – Sam Kottler single milestone. MONITORING AND CHANGE CONTROL
Managing Change for Existing Test cases: An existing test case evolves with changes in requirements and might become valid, invalid or would need enhancements. In such cases, the test cases are changed from 'Approved' State to 'Draft' so that regular test case life cycle is started again (update, review, execution). Since this represents a new unit of work, a new Test Execution Record is created in Backlog first and then moved to the milestone in which it’s planned to be developed as described earlier. Thus test cases will have multiple TER's in development each representing a traceable change history of the test cases. In regression the existing TER only captures the latest results.
REPORTING AND TRACKING Project reporting and Tracking is done to ensure requirements coverage, test case development and execution progress through different widgets on RTC Project Area Dash board. Main reports that are used for this purpose are: REQUIREMENTS Requirements to Test Case Trace-ability Matrix. Requirements to Development Task Traceability Matrix.
Requirements Coverage at end of each iteration through test cases completion score.
All the sub requirements within a requirement which have not been covered by a test case are highlighted in green. As they get covered the green highlighting is removed.
QUALITY MANAGEMENT Test Execution Status. Testing Automation Status i.e. Manual V/s Automated Tests. Test case development completion and execution would decide the product development progress. WORK BREAK DOWN
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 30
RTC Queries: Work Item’s can be tracked through different queries created under Project Area -> Work Items -> Shared Queries -> Development. A true picture of project progress is obtained through the test cases completion percentage.
BENEFIT TDD process implementation has improved the product quality as developers have detailed understanding of the requirements through different possible test scenarios. They are able to raise issues during development of the test cases itself. Time to fix the defects has reduced as developers execute and fix all the test cases written by testing team.
Bit
8
Vivek Gupta is an engineering manager in the Corporate Tools Team of SWG in IBM-ISL and has been with IBM for over 7 years. In his current role he is managing the team responsible for sustenance and enhancement of IBM Legacy Tools and their migration strategies to latest IBM Rational Products. He has an overall 17 years of software industry experience. Deepa Saini, PMP is currently working with IBM-ISL as a Software Release Manager in the Corporate Tools Team of SWG. She has an overall experience of 15 plus years in the software industry. She is well versed with all the software engineering practices and has also been an internal auditor for CMM assessment.
Terabyte 1024 Gigabyte 1024 Megabyte 1024 Kilobyte 1024 Byte
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Revising thoughts of computing powers
Synergy Mar 2014, Page 31
It gives immense pride to share that Vimal Khanna, who was a Technical Presenter at PMI National Conference, 2013 has struck another feather in his cap. The article that he presented at the conference “Managing Small Teams - Look beyond Process Simplification” has been published in the March edition of PMI Asia Pacific –link. PMI salutes his spirit of constantly moving forward and for the benefit of readers, we have included his article in this Synergy Edition.
You said it & We did it Puneet Gupta — “The contributors are the most important element in the magazine content creation. Currently, the name of the Author along with a brief write up of author is included in the magazine. The effectiveness of collaboration will increase, if we can include LinkedIn link for the authors too. It will help project managers to connect and discuss about the Project Management activities across the peers on social networking sites too. It may also have spiral effect on bringing the chapter members and non-members together on number of issues.”
Feedback: pminicmag@pminorthindia.org, Prashant@pminorthindia.org
Synergy Mar 2014, Page 32