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
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
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
Hands on or hands off what suits it business heads better
ACE Blog Article Home Hands-on or hands-off – What suits IT business heads better? 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 Hands-on or hands-off – What suits IT business heads better? September 7th, 2015 Posted by: admin Leadership approach for IT business heads – hands off or hands on? Have you come across situations where business heads in software organizations – Are uncomfortable in facing the development team. As a result, they don’t mingle with the teams easily and use authority of their position to demand results? Are uncomfortable talking to customers about any technicalities of the project and restrict themselves to discussing commercials? Are found inadequate to take proactive measures when software delivery results are not up to the expectations? Well, the above scenario is not too uncommon and there are many reasons for it. A business head in an IT organization can get into that position from a variety of career paths such as finance, HR and sales. Not all of them would have passed through the mill of end-to-end project delivery to understand the nitty-gritties of software delivery. And apparently many of them don’t need this understanding for their day-to-day functioning as their typical job involves meeting customers, building relationships, discussing commercials and closing the deals while delivery is taken care of by project managers. In summary, many business heads who get into that position laterally don’t have background in software delivery and don’t need it either for their day-to-day functioning in business matters but face certain limitations while dealing with delivery. Therefore, the question that arises is whether this hands-off approach is just fine or the business heads have to do something to become hands-on? In other words, do business heads need a certain level of awareness about software project management? What do they lose if they don’t have that awareness and what do they gain if they develop that awareness? As we will examine in this article, business heads stand to gain tremendously if they develop a basic level of skills in project management and there are 3 main reasons for doing so. In order to understand the 3 reasons, we have to first make clear the interrelation between software delivery results and business results at a parametric level. Impact of software delivery on IT business results While it is common knowledge that a high quality software delivery can lead to better business results, what is not evident is how it happens. Skill set of project managers and processes are two key areas of delivery excellence. Process and its skillful application result in improved delivery metrics. And some of these metrics directly translate into business results including topline and bottom line growth as shown in the diagram. business-results-of-project-management-skills Project management skills to business results road map The range of skills and process areas in software delivery is quite vast and trying to improve everything would not only be a poor choice from an ROI perspective, but would be ineffective as well. Apart from the 23 process areas that CMMi lists, there are other areas that CMMi doesn’t touch. Refer ” ” for more details. There are skills such as estimation, requirement elicitation, requirement management, planning and tracking, risk management, test management, quality management, team leadership, communication to name a few. Training future project managers on all the skills relevant to project management would be as much of a syllabus as that of a master’s degree in project management which organizations can ill afford if all of their staff have to go through it. Therefore, choosing the right subset of skills to train future project managers, choosing the right process areas for rigorous implementation are key to success and this is where the business leader has to play a key role. The business leader has to provide direction in ensuring that the right skill sets and process areas that suit their business context are chosen. And driving delivery excellence in such a way that improvement in delivery is tracked all the way up to business results is also a responsibility of the business leadership. Hence, a business leader needs some high-level knowledge of software project management to be able to make the right choices, drive delivery excellence and ensure that delivery excellence translates into business benefits. Relating delivery excellence to business results Going into further details, the choice of process areas and skill sets has to be based on the delivery parameters or metrics targeted. Carving out a road map for delivery excellence has a method to it; the business head has to first choose the delivery metrics that have maximum impact on business results in their context and then choose the processes and skill sets that can specifically improve these metrics. There is a wide variety of metrics available in the software industry and a business leadership has to choose those metrics that make sense in their business context. This is a key area where thought leadership of the business head plays a crucial role. There are a variety of delivery parameters or metrics at various levels of the organization and each has an impact on different business parameter as illustrated in the diagram. The business leadership should have an understanding of this relationship. IT-business-metrics Comparison of IT business parameters In summary, choosing the right delivery metrics to target, choosing the right set of skills and processes to improve the targeted metrics is a responsibility of business leadership. Even if this is done by delivery teams or a hands-on delivery, head, it is the responsibility of business leadership to get it done. The 3