Procurement Management Procurement management process involves managing the order, receipt, review and approval of items from

suppliers. Procurement management also specifies about the management of supplier relationships, to ensure better service. This is a critical task in Procurement Management. In short, the procurement process helps you "get what you have paid for". Procurement Management has been developed to suit the needs of professionals to include all aspects of procurement including Purchasing, Logistics, Supply Chain Management and International Sourcing. The course is designed to equip individuals with skills and understanding that will enable them to make a contribution to development of competitive advantage. The course focuses on new development tools of harmonization, and simplification.

After completing the education you can join as Procurement Manager. Key responsibility of a procurement manager is areas of negotiation in all sub contracts and materials procurement/ identification of new suppliers, supplier alignment, relationship and development. He also contributes to the policy setting and manages the administration of procurement. Along with Procurement Manager also manages the activities of service delivery - committed to customers at the right time, cost and quality, control and measure performance to ensure service levels are in line with business objectives. He also manages and maintains standard contract conditions. Project portfolio management (PPM) Project portfolio management (PPM) is a term used by project managers and project management (PM) organizations, or PMOs, to describe methods for analyzing and collectively managing a group of current or proposed projects based on numerous key characteristics. The fundamental objective of PPM is to determine the optimal mix and sequencing of proposed projects to best achieve the organization's overall goals - typically expressed in terms of hard economic measures, business strategy goals, or technical strategy goals - while honoring constraints imposed by management or external real-world factors. Typical attributes of projects being analyzed in a PPM process include each project's total expected cost, consumption of scarce resources (human or otherwise) expected timeline and schedule of investment, expected nature, magnitude and timing of benefits to be realized, and relationship or inter-dependencies with other projects in the portfolio. Some commercial vendors of PPM software emphasize their products' ability to treat projects as part of an overall investment portfolio. PPM advocates see it as a shift away from one-off, ad hoc approaches to project investment decision making. Most PPM tools and methods attempt to establish a set of values,

techniques and technologies that enable visibility, standardization, measurement and process improvement. PPM tools attempt to enable organizations to manage the continuous flow of projects from concept to completion. Treating a set of projects as a portfolio would be, in most cases, an improvement on the ad hoc, one -off analysis of individual project proposals. The relationship between PPM techniques and existing investment analysis methods is a matter of debate. While many are represented as "rigorous" and "quantitative", few PPM tools attempt to incorporate established financial portfolio optimization methods like modern portfolio theory or applied information economics, which have been applied to project portfolios, including even non-financial issues. Eight Key Factors to Ensuring Project Success Introduction: As the project manager you are ultimately responsible for delivering a successful project. The buck stops with you, so it is in your interest to ensure relevant tools and techniques are deployed to make this happen. Some of the following may sound obvious but I encounter these basic mistakes month in month out with project managers scratching their heads wondering how and why it all went wrong. Business Case: Ensure that there is a strong business case, with high level support, that everyone can buy into. The business case is the justification for the project and should list the expected benefits. This is something everyone involved in the project can focus on and the reason why the project is taking place. Projects move us from one state to another by deliver a change, product or other desired outcome, with the business case explaining why. Critical Success Factors: Define with the customer the Critical Success Factors that will make the project a success. Ensure that you make them measurable e.g. a 20% reduction in the cost of raw materials by the end of the year. Use these factors at the end of the project to measure your success. This is all that counts and the must have items that the project needs to achieve. All other issues are secondary to these as the Critical Success Factors effectively form your contract with the customer. Planning: Time spent planning is time well spent. All projects must have a plan with sufficient detail so that everyone involved knows where the project is going. A good plan provides the following benefits:

Clearly documented project milestones and deliverables A valid and realistic time-scale Allows accurate cost estimates to be produced Details resource requirements Acts as an early warning system, providing visibility of task slippage Keeps the project team focused and aware of project progress

To skimp on this area is likely to lead to problems. Ensure that you build in contingency to any estimate. I recommend between 10 and 15 percent. I prefer to be a little pessimistic and deliver early rather than too

optimistic and deliver late. Be careful though, add too many contingencies and you could give the impression of being inefficient. Team Motivation: A motivated team will go that extra mile to deliver a project on time and to budget. Keep your team motivated by involving them throughout the project and by planning frequent milestones to help them feel they are making progress. Communication is key here, so let your team know when they are performing well, not just when they are performing badly. Saying No: Believe it or not some project managers and some team members come to that, have a problem saying no. Never promise anything you know you can't deliver, you are just storing up problems for later. Stick to your guns no matter how senior or important the person is, they'll thank you for it later. If they don't perhaps you're in the wrong job. When saying no, be firm and prepared to justify the reasons behind your decision. Avoiding Scope Creep: Scope creep is one of the most common reasons projects run over budget and deliver late. Don't forget the customer will forget the extra work and effort you have put in, insisting that you have delivered what they asked for originally. Ensure that you set expectations correctly at the outset of the project and clearly define what is in and out of scope. Record it in the key project document. Don't assume the customer will read and understand this document. I recommend that you spend an hour with the customer to walk them through the project and ensure that they understand and agree the scope. Don't proceed without a firm agreement. Risk Management: Nobody likes to think about risks especially early on in a project. Avoid risk management at your peril. I recommend that you produce a risk log with an action plan to minimize each risk and then publish it to all the key stakeholders in your project. Knowing what action you will take, should the worst happen, will be a great comfort. Project Closure: Remember that projects have a finite life. A project that isn't closed will continue to consume resources. It's in the customer's interest to keep the project open so they can add new features and functionality as they think of them. At the end of a project be firm, agree with the customer that the Critical Success Factors have been met, the project delivered, tested, released and ask them to sign the project off. I like to use a Customer Acceptance Form that I lodge with the Project Office. At this point you may like to ask you customer to fill out a satisfaction survey. They may have valuable information that can help you and your team improve for future projects. Conclusions: Applying these eight simple techniques will help you avoid many common problems that befall many project managers. The key to good project management is communication with the project stakeholders. Never leave it too late to tell people what is happening, bad news only gets worse the longer you leave it.

Project Health Check: Finally, here is a checklist that you can use to test the health of your project. Score each question using the grading shown to arrive at a total score and then check the overall health of your project using the table below. I.T project manager skills _ Customer focusemployee possesses knowledge of customers business needs and expectations; delivers constructive qualitative feedback to customers, meets deadlines, and works with customers to set requirements and schedules _ Technical skillsemployee possesses skills related to programming, computer-aided software engineering, desktop client services, enterprise infrastructure applications, technical software, and hardware support _ Product or technology evaluation and expertiseemployee analyzes and compares products, makes sound recommendations within the company architecture, understands and recognizes limitations of technologies, can communicate the fundamentals of technology to others, and uses technical team resources to resolve or avoid technology-based problems _ Business and application expertiseemployee possesses knowledge of business-specific applications, knows companys business and local operations, knows the broad application environments (e.g., order entry and accounting), and understands general concepts of business management _ Project managementemployee handles projects of certain size and complexity, estimates project costs and schedules with a degree of accuracy, executes project to plan, manages multiple projects at once, builds teams and organizes team resources, and knows project management tools _ Interpersonal skillsemployee performs as team member or team leader, contributes knowledge to the team and to the organization, and communicates effectively _ Administrative skills employee has understanding of budgeting, interviewing, economics of the business, and salary and review process Soft skillsemployee displays leadership, forward thinking, initiative, drive for education, and commitment to organizational structure and development.
_

1. Water Fall Model (Linear Sequential Model) 1) It is a simplest model, which states that the phases are organized in a linear order. 2) The model was originally proposed by Royce. 3) The various phases in this model are a) Feasibility Study The main aim of the feasibility study activity is to determine whether it would be financially and technically feasible to develop the product. The feasibility study activity involves the analysis of the problem and collection of all relevant information relating to the product such as the different data items which would be input to the system, the processing required to be carried out on these data, the output data required to be produced by the system as well as various constraints on the behavior of the system. b) Requirement Analysis The aim of the requirement analysis is to understand the exact requirements of the customer and to document them properly. The requirement analysis activity is begun by collecting

all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussions. During this activity, the user requirements are systematically organized into a software requirement specification (SRS) document. The important components of this document are the functional requirements, the nonfunctional requirements, and the goals of implementation. The SRS document is written in end-user terminology. This makes the SRS document understandable by the customer. After all, it is important that the SRS document be reviewed and approved by the customer. c) Design This phase is concerned with 1) Identifying software components like functions, data streams and data stores. 2) Specifying software structure. 3) Maintaining a record of design decisions and providing blue prints for the implementation phase 4) The are two categories of Design a) Architectural Design It involves 1. Identifying the software components. 2. Decoupling and decomposing the software components into modules and conceptual data structures. 3. Specifying the interconnection between the various components. b) Detailed Design It is concerned with details of the implementation procedures to process the algorithms, data structures and interaction between the modules and data structures. The various activities that this phase includes are 1. Adaptation of existing code. 2. Modification of existing algorithms. 3. Design of data representation and 4. Packaging of the software product. This process is highly influenced by the programming language under the implementation would be carried out. This stage is different from implementation. d) Implementation It involves the translation of the design specifications into source code. It also involves activities like debugging, documentation and unit testing of the source code. In this stage various styles of programming can be followed like built-in and user defined data types, secure type checking, flexible scope rules, exception handling, concurrency control etc. e) Testing It involves two kinds of activities 1. Integration Testing It involves testing of integrating various modules and testing there overall performance due to their integration. 2. Acceptance Testing It involves planning and execution of various types of tests in order to demonstrate that the implemented software system satisfies the requirements stated in the requirements document. f) Maintenance In this phase the activities include 1. Corrective Maintenance Correcting errors that were not discovered during the product development phase. 2. Perfective Maintenance Improving the implementation of the system, and enhancing the functionalities of the system according to customers requirements. 3. Adaptive Maintenance Adaptation of software to new processing environments.

Advantages of Water Fall model 1. All phases are clearly defined. 2. One of the most systematic methods for software development. 3. Being oldest, this is one of the time tested models. 4. It is simple and easy to use. Disadvantages of Water Fall Model 1. Real Projects rarely follow sequential model. 2. It is often difficult for the customer to state all requirements explicitly. 3. Poor model for complex and object oriented projects. 4. Poor model for long and ongoing projects. 5. High amount of risk and uncertainty. 6. Poor model where requirements are at a moderate to high risk of changing. Milestones 1) These are a set of occasions in project design where the proper progress of the project can be assessed in such a way that corrective measures could be taken if necessary. a) The two major milestones are i. Preliminary Design Review (PDR) :- Its normally held near the end of architectural design and prior to detailed design ii. Critical design Review (CDR) :- Its normally held at the end of detailed design and prior to implementation.

b) The major goal of PDR is to demonstrate the externally observable characteristics and architectural structure of the product which would satisfy the customers requirements. Functional characteristics, performance attributes, external interface, user dialogs, report formats, exception conditions and exception handling and future enhancements are reviewed during PDR. c) The CDR provides a final management decision point , to build or cancel the system.

SRR :- Software Requirements Review PDR :- Preliminary Design Review. CDR :- Critical Design Review. White Box Testing (Gloss Box Testing) (Structural Testing) 1. In this testing technique the internal logic of software components is tested. 2. It is a test case design method that uses the control structure of the procedural design test cases. 3. It is done in the early stages of the software development. 4. Using this testing technique software engineer can derive test cases that: a) All independent paths within a module have been exercised at least once. b) Exercised true and false both the paths of logical checking. c) Execute all the loops within their boundaries. d) Exercise internal data structures to ensure their validity. Advantages: 1. As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type of input/data can help in testing the application effectively. 2. The other advantage of white box testing is that it helps in optimizing the code. 3. It helps in removing the extra lines of code, which can bring in hidden defects. 4. We can test the structural logic of the software. 5. Every statement is tested thoroughly. 6. Forces test developer to reason carefully about implementation. 7. Approximate the partitioning done by execution equivalence. 8. Reveals errors in "hidden" code. Disadvantages: 1. It does not ensure that the user requirements are fulfilled. 2. As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this type of testing, which increases the cost. 3. It is nearly impossible to look into every bit of code to find out hidden errors, which may create problems, resulting in failure of the application. 4. The tests may not be applicable in real world situation. 5. Cases omitted in the code could be missed out.

Black Box Testing (Behavioral Testing) (Closed box Testing) 1. This technique exercises the input and output domain of the program to uncover errors in program, function, behavior and performance. 2. Software requirements are exercised using black box test case design technique. 3. It is done in the later stage of the software development. 4. Black box testing technique attempts to find errors related to: a) Missing functions or incorrect functions. b) Errors created due to interfaces. c) Errors in accessing external databases. d) Performance related errors. e) Behavior related errors. f) Initialization and termination errors. 5. In Black box testing the main focus is on the information domain. Test is designed for following questions: a) How is functionality validation testing? b) What class of input will make good test cases? c) Is the system particularly sensitive to certain input values? d) How are the boundaries of a data class isolated? e) What data rates and data volume can the system tolerate? f) What effects will specific combinations of data have on system operation? Advantages: 1. More effective on larger units of code than glass box testing. 2. Tester needs no knowledge of implementation, including specific programming languages. 3. Tester and programmer are independent of each other. 4. Tests are done from a user's point of view. 5. Will help to expose any ambiguities or inconsistencies in the specifications. 6. Test cases can be designed as soon as the specifications are complete. Disadvantages: 1. Only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever. 2. Without clear and concise specifications, test cases are hard to design. 3. There may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried. 4. May leave many program paths untested. 5. Cannot be directed toward specific segments of code which may be very complex (and therefore more error prone). 6. Most testing related research has been directed toward glass box testing. Unit Testing Advantage of Unit Testing 1. Can be applied directly to object code and does not require processing source code. 2. Performance profilers commonly implement this measure. Disadvantages of Unit Testing 1. Insensitive to some control structures (number of iterations) 2. Does not report whether loops reach their termination condition 3. Statement coverage is completely insensitive to the logical operators (|| and &&).

Integration Testing Top-down Integration Top-down integration testing is an incremental approach to construction of program structure. Modules are integrated by moving downward through the control hierarchy, beginning with the main control module (main program). Modules subordinate (and ultimately subordinate) to the main control module are incorporated into the structure in either a depth-first or breadth-first manner. Bottom-up Integration Bottom-up integration testing, as its name implies, begins construction and testing with atomic modules (i.e., components at the lowest levels in the program structure). Because components are integrated from the bottom up, processing required for components subordinate to a given level is always available and the need for stubs is eliminated. Software Project Management Project management involves the planning, monitoring and control of the people, process and events that occurs as software evolves from a preliminary concept to an operational implementation. Software project management is an umbrella activity within software engineering. It begins before any technical activity is initiated and continues throughout the definition, development and support of computer software. The project management activity encompasses measurements and metrics estimation, risk analysis, schedules, tracking and control. Effective software project management focuses on the four Ps: people, product, process, and project. The order is not arbitrary. The manager who forgets that software engineering work is an intensely human endeavor will never have success in project management. A manager who fails to encourage comprehensive customer communication early in the evolution of a project risks building an elegant solution for the wrong problem. The manager who pays little attention to the process runs the risk of inserting competent technical methods and tools into a vacuum. The manager who embarks without a solid project plan jeopardizes the success of the product. 1. The People a) The people factor is so important that the Software Engineering Institute has developed a people management capability maturity model (PM-CMM). b) To enhance the readiness of software organizations to undertake increasingly complex applications by helping to attract, grow, motivate, deploy, and retain the talent needed to improve their software development capability. c) The PM-CMM is a companion to the software capability maturity model that guides organizations in the creation of a mature software process. d) The PMCMM defines the following areas for software people. a. Recruiting b. Selection c. Performance Management d. Training e. Career Development f. Team Culture Development 2. The Product Before a project can be planned,

a) Product objectives and scope should be established. b) Alternative solutions should be considered. c) Technical and management constraints should be identified. d) The software developer and customer must meet to define product objectives and scope. e) Objectives identify the overall goals for the product (from the customers point of view) without considering how these goals will be achieved. f) Scope identifies the primary data, functions and behaviors that characterize the product, and more important, attempts to bound these characteristics in a quantitative manner. 3. The Process a) A software process provides the framework from which a comprehensive plan for software development can be established. b) A small number of framework activities are applicable to all software projects, regardless of their size or complexity. c) A number of different tasks settasks, milestones, work products and quality assurance points enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team. d) Umbrella activitiessuch as software quality assurance, software configuration management, and measurementoverlay the process model. 4. The Project a) We conduct planned and controlled software projects for one primary reasonit is the only known way to manage complexity. b) The overall development cycle is called as Project. c) In order to avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring and controlling the project. Risk Management Risk analysis and management are a series of steps that help a software team to understand and manage uncertainty. Many problems can plague a software project. A risk is a potential problemit might happen, it might not. Risk Identification Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.). By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary. One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic categories: risks associated with the overall size of the software to be built or modified. risks associated with constraints imposed by management or the marketplace. risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner. risks associated with the degree to which the software process has been defined and is followed by the development organization. risks associated with the availability and quality of the tools to be used to build the product.

risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system. risks associated with the overall technical and project experience of the software engineers who will do the work. Risk Projection Risk projection also called risk estimation, attempts to rate each risk in two waysthe likelihood or probability that the risk is real and the consequences of the problems associated with the risk, should it occur. The project planner, along with other managers and technical staff, performs four risk projection activities: (1) Establish a scale that reflects the perceived likelihood of a risk, (2) Delineate the consequences of the risk, (3) Estimate the impact of the risk on the project and the product, and (4) Note the overall accuracy of the risk projection so that there will be no misunderstandings. Risk Assessment At this point in the risk analysis process we have established a set of triplets of the form : [ri,li,xi] Where ri is risk, li is the likelihood (probability) of the risk, and xi is the impact of the risk. During risk assessment, we further examine the accuracy of the estimates that were made during risk projection, attempt to rank the risks that have been uncovered, and begin thinking about ways to control and/or avert risks that are likely to occur. Therefore, during risk assessment, we perform the following steps: 1. Define the risk referent levels for the project. 2. Attempt to develop a relationship between each (ri, li, xi) and each of the referent levels. 3. Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty. 4. Try to predict how compound combinations of risks will affect a referent level. Risk Mitigation, Monitoring, and Management 1. An effective strategy must consider three issues: a) Risk avoidance b) Risk monitoring c) Risk management and contingency planning 2. High staff turnover in any organization will have a critical impact on project cost and schedule. 3. To mitigate the risk, project management must develop a strategy for reducing turnover. Among the possible steps to be taken are ine causes for turnover Mitigate those causes that are under our control before the project starts. when people leave. information about each development activity is widely dispersed. a timely manner. ry critical technologist.