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!
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
Essential project management other than PMI
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.