Klara Södra 1, 111 52 Stockholm

Contact us today - 98457 ACEPM (98457 22376)

Comparing strategic and tactical outsourcing

ACE Blog Article Home Comparing strategic and tactical outsourcing Posts categories For L & D Heads For Business heads For PMs Delivery Excellence Agile methods Complex project management Skills and competencies Assessment Outsourcing Certifications and Career Recent posts IT trends: Will the Indian IT industry survive through the smart app explosion? Comparing strategic and tactical outsourcing Requirement change management by leveraging project constraints Is the schedule driving the project or vice versa What the CMMi and PMBoK don't tell you How can we help you? Send Outsourcing: Comparing strategic and tactical outsourcing September 7th, 2015 Posted by: admin Introduction There are a number of seemingly independent factors that have contributed to the emergence of strategic outsourcing and this article explores briefly, the development of software industry from this perspective and compares tactical and strategic outsourcing at the end. Tactical outsourcing From an Indian software industry perspective, outsourcing took shape in the early 90’s mainly in a tactical way. The concept that was sold to the global IS shops, was that of an ODC (Offshore Development Centre) model which was touted as an extended arm of the customers’ IS team. In the 90’s, before the dot com bubble burst, the CIO (Chief Information Officer) had most of the say in how IS budget would be spent and took outsourcing decisions. Outsourcing was taken up mainly to reduce staffing costs and it was mainly coding work that was outsourced. The higher-end work still retained at the customer’s side and all business-critical work was handled by customer’s team. Most of the project management was done by the customer’s team although there would be a project manager located at offshore to co-ordinate the activities at offshore. This mode of outsourcing is termed tactical outsourcing and summarizing, factors that characterized tactical outsourcing era are –. This mode of outsourcing is termed tactical outsourcing and summarizing, factors that characterized tactical outsourcing era are – The off-shore team was seen as an extended arm and outsourcing was done mostly as staff augmentation at lower cost under time & material model. 2. The customer’s team carried the project management responsibilities and the off-shore team was answerable mainly to the project manager from the customers’ organization. 3. Outsourcing decisions were made by the CIO.4. Most of the higher-end work was retained at on-site and predominantly coding was pushed to the off-shore team. Strategic outsourcing This scenario changed in the next decade (’00s) which saw the Indian industry raising up on the learning curve and becoming competent to handle project management as well as higher-end project activities such as requirements elicitation and architecting. The dot com bubble burst caused a series of changes in the way IS decisions were made. Organizations became more wary of spending on IT and IT spending decisions were made by a committee involving the CIO, business sponsors, finance team etc. and not by the CIO alone. ROI (Return On Investment) measurement from IT spending became more rigorous. As a result, customers started favoring fixed-price model for software application development where end-to-end responsibilities of a project are carried by the offshore development team. With this background, the next development was commencement of strategic outsourcing initiatives where a portfolio of applications is identified and the end-to-end responsibilities of all the applications in the portfolio are transferred in a phased manner to the vendor with the IS department carrying minimum responsibilities. In a strategically outsourced project, the development team from the vendor (could be partly located at offshore and partly on-site) carries not only the end-to-end responsibilities of the project, but also manages all the stake holders of the project. With maximum possible reduction of IS staff, a strategic outsourcing initiative yields maximum cost saving but demands new competencies to manage vendors and ensure successful project delivery. The risks of project failures are higher in strategic initiatives as it provides poor visibility into how the project is being managed by the vendor. This mode of outsourcing is called the strategic outsourcing and can be summarized as below – The last decade has seen the raise of Indian software industry on the value chain where they take up end-to-end responsibilities of a software project that include, requirements, architecture, project management and management of stake holders. The IT spending and decision making pattern in customer organizations has changed and ROI measurement from IT spending has become more rigorous. Decision making involves a committee rather than CIO alone. Customers have started favoring fixed price model for software application development to begin with and at higher-end they prefer transferring end-to-end responsibilities of a portfolio of applications Customers have less visibility into the development of applications and run the risk of losing control over the course of the project. Comparison summary Criterion of comparison Tactical outsourcing Strategic outsourcing Outlook / Philosophy Offshore team is an extended arm Offshore team carries responsibility and reduces my burden Nature of work outsourced Coding, mainly End-to-end responsibility of applications Responsibility sharing Off-shore team answerable to customer contact Off-shore team answerable to stakeholders of the project Business model Staff augmentation / Time and material, predominantly Fixed price model, predominantly Transition of work Parts of applications as and when needed Portfolio of applications in a planned manner Risks Risks are fairly less as customer carries project management responsibilities Risks are more as customer has less visibility of the course of application development Benefits Reasonable Higher benefits with least staff to be supported Conclusion In summary, strategic outsourcing can be more beneficial than tactical outsourcing but can be more risky as well. It needs development of new competencies on the part of IS managers to ensure successful delivery in a strategic outsourcing environment. Share This Story, Choose Your Platform!

Requirement change management by leveraging project constraints

placeholder.png

ACE Blog Article Home Requirement change management using project constraints Posts categories For L & D Heads For Business heads For PMs Delivery Excellence Agile methods Complex project management Skills and competencies Assessment Outsourcing Certifications and Career Recent posts How can we help you? Requirement change management using project constraints September 7th, 2015 Posted by: admin Requirement change management using project constraints Project constraints or dimensions The PMBoK (Project Management Body of Knowledge) lists three entities as project constraints – scope, cost and time. Also known as triple constraints, the iron triangle these elements have come to be classified as project dimensions of late. The term dimension is more suitable as each dimension can act as a lever for the project using which we can guide the project towards the end delivery. Each of these dimensions can be a driver or a contraint or a degree of freedom as explained below. The key to project success is in identifying what dimension is a driver, which dimension is a constraint and which dimension is a degree of freedom and always leveraging the degree of freedom to navigate the project. This article illustrates identifying and classifying the dimensions, leveraging the degree of freedom to respond to requirement changes. The types of project dimensions: Driver: A project dimension such as scope, or time or cost is called a driver when that is the reason for the existence of the project. In some projects, special features are critical to its business success and scope will be a driver for such projects. Similarly for some products, the features are common with the features of other competing products, but being the first to market is essential for business success. In such a case, time as a dimension will be the driver for the project. Constraint: Any project dimension can be a constraint if it cannot be changed. In the above example, when feature is a driver, and there is a fixed time by which the product has to be released, time will become a constraint. On the other hand, for some projects that have a limited budget, cost can be a constraint Degree of freedom: Any project dimension which can be increased or decreased, on which the project manager can exercise a certain flexible control is called a degree of freedom. For instance, in a business critical product that is driven by a time-to-market strategy, a certain minimum feature set is a necessity, and the project is well funded, the time would be a driver (the faster the release, the better it is for the business; so the teams are supposed to chase time); feature set and hence scope would be a constraint because it cannot be either reduced or increased. Cost can be a degree of freedom as the project is well funded. How the project dimension analysis will be helpful for responding to changes will be illustrated in the later sections of this article. The problem of requirement change managemenet There are many instances where software project managers are stuck in an unanticipated project situation after which the project slips from their grip and takes its own course. Quite often, requirement changes are the reason for the project to slip out of control and project managers are at a loss when the changes are too many. The project also goes out of control because the project managers are often unable to respond with the right strategy to the changes and are unable to carry the customer with their requirement change management strategy. This is because, they don’t identify the right degree of freedom for the specific project and devise their change management plan based on the degree of freedom. Leveraging the degree of freedom is a very powerful way to wriggle out of such situations, carry the customer along and keep the project on track. Illustrating the use of project dimensions Consider the following situations – 1. Project is on track, design is underway and the customer comes up with a major additional requirement. The team responds in a standard way by applying the change control procedure, carrying out impact analysis, reworking the schedule, cost and presents it for customer’s approval. The customer doesn’t agree and insists that the additional requirement must be accommodated in the existing plan itself. He would have a number of reasons on his side to demand so. The team knows that this is infeasible but still agrees with the customer and carries on; however, because of in-feasibility of the current plan, the project drifts off the track and takes its own course. How to resolve this situation and keep the project on track? 2. Complexity of certain features was not fully understood initially and completion of certain milestones has taken much more time than planned and the project delivery will be delayed. Customer is approached for extension of schedule, but he refuses. Project team works with the original schedule, but cannot meet it and the project drifts off course. How to resolve this situation? A common perception about response to such situation is to put the onus on soft skills of the project manager – being assertive, ability to convince, ability to negotiate and so on. The underlying expectation is that a project manager endowed with these soft skills would be able to wriggle out of these situations better. While the importance of these soft skills is not denied, a flaw in this expectation is that it is team-centric and not customer-centric. More than the ability to assert a given team’s position, one needs to understand the customer’s position and identify a win-win strategy. The project dimension analysis helps in understanding the customer’s drivers, constraints and degrees of freedom and identify such a win-win way out of the situation. The soft skills then comes in handy in convincing the customer about this win-win strategy and get his / her concurrence.In order to appreciate the importance of dimension analysis, one should dig into why it is difficult to get

Is the schedule driving the project or vice versa

placeholder.png

ACE Blog Article Home Is the schedule driving the project or vice versa Posts categories For L & D Heads For Business heads For PMs Delivery Excellence Agile methods Complex project management Skills and competencies Assessment Outsourcing Certifications and Career Recent posts How can we help you? Share This Story, Choose Your Platform! Is the schedule driving the project or vice versa? Note: This article was first published on Knowledge Hut Blog, our blog partner.  Are you familiar with a situation where a project manager diligently drafts a project schedule and uses it to drive the project for 2-3 weeks and then the schedule goes into cold storage? Either the schedule disappears or gets driven by the project getting executed independent of the schedule. Most people that I interact with tell me that this is a very common scenario. Why does this happen? How can it be avoided and how can we draft an effective schedule that can actually be used to drive the project till its completion? What are the characteristics of such an effective schedule? Why should a project manager take pains to draw up such an effective schedule and what are the benefits? We have done some research in this area by studying a number of real project schedules and would like to present the findings in this article. Why effective schedules are important? One of the major challenges faced by the software industry is delivering fixed price projects profitably. And poor scheduling is one of the top three areas of challenge, the other two being poor estimates and poor requirements management. While leading a delivery excellence program, I happened to interview several roles and one business unit head revealed that he had won a million dollar deal recently and assigned the best PM of the BU to the project. And when that PM came up with a draft schedule, it had a built-in overrun of 5%. Projects typically follow the Murphy’s law “work expands to fill duration” and people tend to consume all of the allocated duration, even if it is in excess, and on top of the built-in 5% overrun, if there is an additional 20% overrun, then the project would move into a loss zone. Incidentally, the BU head was a pro in scheduling, he sat with the PM, optimized resource allocation and then the schedule came down to utilize only 85% of the originally estimated effort. Mind you, this schedule did not reduce the effort or duration of individual tasks but just carried out resource optimization and boom, the effort reduces by 20%!! This incident highlights that well drafted schedules can play a major role in profitability of fixed price projects. And the ROI can also be huge as spending ½ a day in scrutinizing the schedule lead to a saving of almost two hundred thousand dollars in this case. What makes schedules unusable? Why do schedules go into cold storage in spite of their critical advantages? Because, these schedule are not usable. What makes schedules unusable? Having researched into dozens of schedules, we have found several common factors that make schedules unusable and the top three reasons are explained below. The task breakdown does not match with the actual tasks that will be performed to realize the end deliverables: Many PMs would be out of touch with software engineering and cannot figure out what activities will be performed and what artifacts will be produced in each phase of the project at a granular level. They may be familiar at a coarse level that analysis, design, coding and testing will be performed but they may not be able to determine exactly what tasks constitute analysis and design and what artifacts will be produced from these tasks. For instance, they may not be identify all the activities and artifacts such as “Design object model”, “Normalize database”, “Create interaction diagrams” that results respectively in object model, database model and interaction diagrams all of them becoming a part of design document. As a result, PM may not be able to document all the tasks in the schedule and the team will be performing many tasks, not accounted for in the schedule. This gap quickly causes misalignment between schedule and actual work. Consequentially, the team stops referring to the schedule for guidance on what to do and the schedule becomes unusable. Estimated duration in the schedule does not match original effort estimates: Many PMs allocate duration to tasks independently instead of deriving them from the original effort estimates. They may not follow any formal method while estimating durations and this makes dates in the schedule mismatch with the actual dates significantly. Although, even the well-drafted, usable schedules can also have mismatch between planned and actual dates, a large-scale mismatch may discourage the team members to use the schedule as a guidance to determine their weekly plan. Resource loading is not optimal: The resources are either under-loaded or overloaded. When the resources are under-loaded, the Murphy’s law “Work expands to fill duration” may kick in and the under-loaded resources may use up all of the available duration (allocated duration and free time) to perform the allocated work resulting in effort and schedule overruns. The overloaded resources obviously cannot perform work according to the schedule and they start performing work independent of the schedule. What makes schedules usable? Having seen the characteristics of unusable schedules, we have also seen the characteristics of usable schedules. It is not necessary that usable schedules are lax schedules. Very tight schedules can also be well-drafted and usable schedules. Our research into schedules that have been successfully used to drive and track projects from inception till end shows that they generally possess a large number of following characteristics. Work breakdown is immaculate The structure of the work breakdown is completely aligned with the software engineering life cycle chosen for the project The WBS covers at least 90% of all activities that will be performed in the project. The amount of time that people spend doing

What the CMMi and PMBoK don’t tell you

ACE Blog Article Home What the CMMi and PMBoK don’t tell you Posts categories For L & D Heads For Business heads For PMs Delivery Excellence Agile methods Complex project management Skills and competencies Assessment Outsourcing Certifications and Career Recent posts How can we help you? What the CMMi and PMBoK don’t tell you Software project management as a field has matured significantly over the past couple of decades and the industry standard frameworks such as the CMMi and PMBoK have played their role in this progress. This raises an interesting question as to what extent these frameworks can be relied upon to ensure successful delivery. Are they complete by themselves or constitute only a part of a complete solution? And if partial what are the additional practices needed to complete ? Primary questions surrounding software delivery To elaborate, let us understand how this question matters to different stakeholders in software delivery: Can a BU (Business Unit) head go for CMMi assessment for organization, PMP certificates for the project managers (PMs) and be assured that delivery results improve automatically? If not, what are the other practices to be implemented? Can a customer rely solely on CMMi assessment and PMP certifications of the vendors and outsource software development to them? If not, what other capabilities should a customer look for among the vendors? Can a PM attend CMMi and PMP classes and be confident that he or she can deliver end-to-end, fixed price projects? If not what additional skills should s/he acquire? When we speak to a number of software professionals across the spectrum and refer to research material (such as ” Scientific Research and Essays Vol. 6(10), pp. 2174-2186, 18 May, 2011 “), we find that these frameworks are good and increases maturity level in software delivery. But they are by no means sufficient and there are problems that persist despite the framework. These problems call for advanced practices beyond CMMi and PMBoK and a closer look at these problems and available solutions is needed. Capabilities and limitations of CMMi and PMBoK The CMMi and PMBoK have many similarities and differences as well. It would be out of scope for this article to examine these differences, and the article will be treating the superset of practices of both the frameworks as a wholeCapabilities: The practices prescribed in the frameworks provide complete solution to a number of issues in software delivery: Configuration management: Many non-CMMi delivery units lack this practice and face consequences such as poor quality, rework and frustration due to absence of version control. Configuration management provides a complete solution. Reviews: This is one area that is the backbone of software quality and CMMi systematizes reviews. Huge benefits such as rework avoidance, better quality can be reaped if reviews are implemented properly. Project tracking and communication: The frameworks introduce discipline in the way projects are tracked and status communicated. Release procedure: Releases are made smoother and flip-flops are avoided by implementing CMMi. Limitations: The limitations are many and cut across multiple areas such as soft skills of project managers, experience, software engineering, technological aspects such as architecture and so on. However, the fact that technology related skills, soft skills and software engineering skills are out of scope for CMMi and PMBoK is well understood. Therefore, this article will be focusing on 3 areas, which are considered very critical to project success, that are within the scope of CMMi and PMBoK, but don’t address adequately and requires software organizations to stretch much beyond implementing CMMi and getting their staff trained on PMBoK. Requirement management – Requirements related practices are well within the scope of both CMMi and PMBoK, but are not adequately addressed as will be analyzed below. Estimation accuracy – Estimation and cost are well within the scope of CMMi and PMBoK, but organizations need estimation methodologies suited to their context and these estimation methodologies don’t come packaged with PMBoK / CMMi. Schedule control – Project schedules are well within the scope of both CMMi and PMBoK, but how to draw effective schedule and use it to deliver project within schedule is an insight that is critical to project success and IT organizations need to go beyond PMBoK and CMMi to get these insights. Analysis of limitations and solutions Poor requirement elicitation: None of the frameworks including agile frameworks have implicit methods for ensuring clarity and completeness of requirement elicitation. While, it may not be feasible to produce at the end of requirements phase, a water-tight set of requirements that will never change, significant improvement is possible. As Leffingwell (Dean Leffingwell, “Managing Software Requirements, A use case approach”, Pearson, 2011) puts it, requirements change because of what are called internal factors and external factors. Internal factors are not eliciting requirements from right stakeholders and non-usage of appropriate elicitation techniques. External reasons are market condition changes, regulatory changes and changes to competitive landscape. While one has to be flexible to incorporate changes due to external factors, changes arising out of internal factors can and must be avoided Solution: Striving to achieve clarity and completeness in requirements elicitation by taking care of internal factors is a practice that IT teams need over and above the industry frameworks. Requirement changes due to internal factors can be eliminated by eliciting requirements from the right stakeholders and usage of right elicitation techniques. High degree of requirement changes: CMMi prescribes that the requirements must be frozen after the requirements phase and subsequent changes must be subject to requirement change control procedure. Enforcing the requirement change control procedure imposes an overhead and when the number of changes becomes too many, the overheads become unmanageable and change control procedure breaks down. Solution: First part of the solution is to reduce the changes by improving requirements elicitation. Second part of the solution is to eliminate requirement changes arising out of communication gap – this needs a good requirements document to the right level of detail. Third part of the solution is to have shorter release cycles and when requirement

Essential project management other than PMI

placeholder.png

ACE Blog Article Home Essential Software project management skills other than PMI Posts categories For L & D Heads For Business heads For PMs Delivery Excellence Agile methods Complex project management Skills and competencies Assessment Outsourcing Certifications and Career Recent posts IT trends: Will the Indian IT industry survive through the smart app explosion? Comparing strategic and tactical outsourcing Requirement change management by leveraging project constraints Is the schedule driving the project or vice versa What the CMMi and PMBoK don't tell you How can we help you? Send Essential Software project management skills other than PMI September 7th, 2015 Posted by: admin Project management skills and competencies needed to be possessed by software project managers is an interesting topic. The project management skills can be divided into two categories – core project management skills and interpersonal skills (or soft skills). The Project Management Body of Knowledge (PMBoK) published by PMI (Project Management Institute) details out the subject areas of core project management skills needed for project managers. When this is so, why this article? Well, the PMBoK does not go into the specifics of software project management and software project managers need skills beyond what is detailed out in PMBoK and this article is about this set of additional skills needed for software project managers Why PMBoK is inadequate for software project management? PMBoK is a very good generalisation of core project management knowledge needed to be possessed by project managers. However, it falls short in the following situations Effort estimation:Software project managers need to be aware of specific software estimation methodologies not covered by PMBoK to ensure accurate estimates. Requirement modelling: Documenting requirements and scope properly is critical to project success. Even though a PM need not carry out the documentation by himself, he needs to ensure that the documentation is done to a required degree of clarity and completeness. This needs some working knowledge of requirements modelling techniques such as ER diagrams, object modelling, use cases and so on, though not an in-depth understanding. Project scheduling: Application of scheduling techniques to software projects using tools such as MS Project Software life cycles: A project manager needs to understand what tasks constitutes the complete project and the task breakdown would be based on the life cycle model being followed. PMBoK only touches the project life cycles and a software PM needs an in depth understanding of the ‘V’ process model, Rational Unified Process, Iterative and Incremental models, Scrum and XP models and so on. Software test management: A project manager should be able to make the right decisions such as whether to continue testing, or carry out a root cause analysis or carry out a partial re-design etc. depending on the intermediate test results. This requires knowledge of characteristics of software quality. Thus, it is evident that a significant additional body of knowledge is required for a PMP certified person to become an effective software project manager The list of skills Based on the above analysis, following is a list of core software project management skills that a software PM needs to possess in addition to PMBoK and interpersonal skills. Ability to organise requirements elicitation workshops resulting in clarity and completeness of requirements Ability to bring the 3 parties – stakeholders, analysts and developers on the same page about what constitutes requirements. The PM needs to ensure clear and adequate documentation of requirements with proper models and needs some working knowledge of requirement modelling and documentation techniques. Requirements management – Ability to anticipate changes, impose change management discipline, avoid scope creep and groom product backlog if using Agile methods. Estimation methodologies – Ability to ensure accurate estimates through use of an appropriate software effort estimation methodology Project planning and tracking – Integrated project planning and tracking with a clear understanding of project dimensions and execution methodology based on life cycle models. Software test management – Knowledge of software testing and decision making during testing phase Project scheduling – Ability to draw up usable schedules using tools such as MS Project and use the schedule to regularly drive the project and track it.

Do you convey WIIFM while assigning roles to team members?

ACE Blog Article Home Do you convey WIIFM while assigning roles to team members? Posts categories For L & D Heads For Business heads For PMs Delivery Excellence Agile methods Complex project management Skills and competencies Assessment Outsourcing Certifications and Career Recent posts How can we help you? Do you convey WIIFM while assigning roles to team members? September 7th, 2015 Posted by: admin Do you convey WIIFM for motivating team? Why WIIFM? Have you come across situations where the team members lack ownership of tasks assigned to them? And because of lack of ownership, does the project manager have to Follow-up frequently? Provide instructions and guidelines on issues that team members are expected to understand and execute by themselves? Motivate them frequently? Well, if this is the case, there is a good chance that the WIIFM for the team members is being ignored while assigning their roles and responsibilities.  WIIFM stands for What’s In It For Me and answering WIIFM is a wide practice in mature organizations to ensure that employees own the responsibilities that they take up. What is WIIFM? Professionals work for many motives – money, designation (reputation), job satisfaction, a penchant for delivering results, networking, diving deep into technology, developing knowledge such as process knowledge & domain knowledge, growth in chosen career path etc.  While an average expected salary level is common for everybody, additional incentives can be quite motivating for some but not for all.  This additional incentive is what we mean by money as a factor of motivation.  Other motivational factors are self-explanatory.  While allocating roles and responsibilities, it helps if the project manager relates the role and responsibility to the career aspiration of the team member.  That is, the question – ‘What’s In It For Me if I take up this role?’ has to be answered for the team member.  If this is done, the team member is most likely to develop ownership of his role and is more likely to be happy to go the extra mile to deliver results.  This insight may appear to be common sense; however, practicing it is quite tricky as it can backfire if not implemented cautiously.  Therefore, analysing the tricky nature of WIIFM and illustrating simple ways of practicing it with real life examples is the purpose of this article. Digging deeper into WIIFM If there is ownership, the team members would not wait for instructions and would travel the extra mile to deliver the results.  On the contrary if the team member lacks ownership, s/he would develop a distance with his/her work and this would not only result in reduced productivity, but also in other consequences such as not being self-driven, not figuring out certain details by themselves etc.  Therefore, it is important to ensure that team members own their work and not develop a distance with it.  This is better illustrated with an experiment. An interesting experiment that I have come across in team building exercises is as follows:  A weighty object, typically a big stone is kept and a boundary strip is marked next to the stone.  Workshop participants have to stand outside the boundary strip, lift the stone and hold it in air as long as they can.  Depending on the weight of the stone, either many participants fail to lift the stone or even if they lift, they won’t be able to hold it for long.  This happens because they are lifting the stone from a distance due to the boundary strip and it requires more energy to lift the stone from a distance.  In the next step, the boundary strip is removed and participants are allowed to stand close to the stone and lift it.  In this attempt, most will be able to lift the stone and hold it much longer than they could, during the first attempt.  Moral of the experiment is that when there is a distance between the task and the performer, execution of the task becomes more tedious. This physical illustration holds true in the emotional sphere also.  If an employee doesn’t feel that the work that he is carrying out belongs to him, then he would find it tedious.  It is because of this tediousness that quality suffers and it takes more time to deliver.  WIIFM would come to the rescue here. Using WIIFM for motivating team in simple ways Dealing with WIIFM can be quite tricky as it can be counter-productive at times.  When the team members’ aspirations are captured, it raises their expectation bar and if there is no attempt to fulfil the aspirations, it can lead to disheartenment and further lack of ownership.  On the other hand meeting the aspirations as-is can also be quite challenging as it may infeasible, or unjustified or may be against company policy.  Some may be expecting a fast promotion and may not yet deserve; giving them promotion raises the expectation bar of others and can be counter-productive on the others.  Some may be expecting a salary increment that may be disproportionate to what they deserve and it may be over and above the company policies.  So, meeting the aspirations as-is could also troublesome.  Therefore, the best way out is to meet the aspirations in a judicious and balanced way.  After capturing the aspirations of the team member, the project manager has to think about them honestly and try to meet the aspirations to the extent possible within the project context.  Two anecdotes below illustrate simple and pragmatic ways in which WIIFM of team members have been fulfilled – The project involved a legacy application based on IBM AS 400 and the project manager did carry out simple one-on-one meetings with the team members during the project initiation.  One of the star performers of the project expressed that he is interested in Java and not in AS 400 technology.  When asked by the project manager as to why he is specific about Java, the team member answered that Java projects are technologically more challenging and handling more challenging