IT trends: Will the Indian IT industry survive through the smart app explosion?
ACE Blog Article Home IT trends: Will the Indian IT industry survive through the smart app explosion? 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 September 7th, 2015 Posted by: admin IT trends: Is the Indian IT industry doomed? Whenever something new looms over the technology or industry horizon, experts are quick to make forecasts. One such forecast that is doing rounds regarding IT trends is that with the explosive growth of customizable third-party apps, business users with little programming skills can assemble applications by themselves and don’t have to depend on their IT departments. IT departments in turn, will not have any work to outsource to their Indian vendors. And the Indian IT industry, therefore is doomed unless they reinvent themselves. This article dissects this doom forecast by taking a closer look at the role of IT departments, the dependence of business on IT departments, and skills needed for assembling larger business applications using smart apps. To quote Vivek Wadhwa, an IT trends observer, he says “With the advent of tablets, apps, and cloud computing, users have direct access to better technology than their IT departments can provide them. They can download cheap, elegant, and powerful apps on their IPads that make their corporate systems look primitive. These modern-day apps don’t require internal teams of people doing software development and maintenance—they are user-customizable and can be built by anyone with basic programming skills.” in a LinkedIn post titled Why I have become pessimistic about Indian IT. Does this generalization hold water? Can the explosive growth of apps render software developers redundant? I am afraid not. There are 3 main reasons as to why users will not be able to do it by themselves and replace IT departments. 1. Rich availability of apps can make programming easier, but IT is lot more than programming: Information Technology is not just programming which is made easy using reusable apps. Identifying the information flowing through a system, breaking them into logical chunks, relating the chunks into a model, identifying the business rules to process information flow and envisaging the whole model as a set of input-process-output is essentially what Information Technology is all about. In other words, any non-trivial application development goes through a software development life cycle that consists of requirements specification, analysis, design, coding and testing. All life cycle models including agile models have these phases, but different life cycle models vary in the extent to which and the sequence in which the life cycle phases are pursued. In this life cycle model coding and unit testing constitutes roughly 30- 40% of the effort and availability of smart, easy-to-use apps can only reduce the effort involved in programming and unit testing to some extent and not the effort for other phases. Effort needed to be spent on other phases would not be reduced significantly as shown in the diagram below. The diagram illustrates that for an application that requires 100 units of effort, the effort required for coding and unit testing reduces from 35 units to 10 units, but effort for other phases remain as-is. It should be noted that the numbers are approximations based on industry averages and there can be variations in specific instances. The critical-to-success skills of IT lies in these non-programming phases, that is, analyzing and modeling customer requirements and designing the software. These non-programming part of IT development skills continue to be necessary both in quantity and quality, and can only be provided by professionals who work full time. Not that non-IT professionals cannot do it. But, they have to invest full time efforts into learning and performing this activity and if they invest that much of time and effort, they in turn become IT professionals whose place is in IT departments. 2. Skills needed for assembling apps with programming the glue code is non-trivial: While I have dealt with large enterprise applications having many lakhs of lines of code, I have also dealt with small software houses developing applications for small businesses with few thousand lines of code. Building dynamic websites for small businesses using customizable frameworks such as Joomla or WordPress has become evermore easier. And yet, believe me, learning Joomla and WordPress is non-trivial to say the least. And it is not a one-time job. One has to spend months of effort to learn not only the framework, but also the innumerable plugins and at least one programming language to write additional code to become competent. And one has to then, continue to keep updating him self or her self by learning features of new releases and latest plugins. It takes months to master these skills and a business user working in some other area of core competency such as an insurance, real estate, inventory or shop floor simply cannot afford this learning curve as an add-on. It requires a full-time effort investment to learn these skills, become proficient and stay updated. Therefore, this do-it-yourself software gadgets may lower the entry bar for a non IT-professional to become an IT Professional; but will not render IT professionals redundant. 3. App explosion, may in fact, lead to increasing the size of pie rather than taking away from it: Let’s take an example of content management systems. Customizing Enterprise Content Management Systems such as OpenText or EMC to specific business requirements demand thorough software development skills whereas customizing small business CMS solutions such as WordPress or Joomla demand relatively less skills. This does not mean that the lower skill level requirement has resulted in WordPress / Joomla eating into the market share of Enterprise CMS products thus rendering the software
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!
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