SMUASSIGNMENT

SEMESTER – 2MBO033

Project managementSet-1

SUBMITTED BY: Gyanendra kumar

MBA ROLL NO:-

520941253

Q1. Explain briefly the life cycle of a project.

Ans1. The Project Life Cycle refers to a logical sequence of activities to accomplish the project’s goals or objectives. Regardless of scope or complexity, any project goes through a series of stages during its life. There is first an Initiation or Birth phase, in which the outputs and critical success factors are defined, followed by a Planning phase, characterized by breaking down the project into smaller parts/tasks, an Execution phase, in which the project plan is executed, and lastly a Closure or Exit phase, that marks the completion of the project. Project activities must be grouped into phases because by doing so, the project manager and the core team can efficiently plan and organize resources for each activity, and also objectively measure achievement of goals and justify their decisions to move ahead, correct, or terminate. It is of great importance to organize project phases into industry-specific project cycles. Why? Not only because each industry sector involves specific requirements, tasks, and procedures when it comes to projects, but also because different industry sectors have different needs for life cycle management methodology. And paying close attention to such details is the difference between doing things well and excelling as project managers.

Diverse project management tools and methodologies prevail in the different project cycle phases. Let’s take a closer look at what’s important in each one of these stages:

1) Initiation

In this first stage, the scope of the project is defined along with the approach to be taken to deliver the desired outputs. The project manager is appointed and in turn, he selects the team members based on their skills and experience. The most common tools or methodologies used in the initiation stage are Project Charter, Business Plan, Project Framework (or Overview), Business Case Justification, and Milestones Reviews.

2) Planning

The second phase should include a detailed identification and assignment of each task until the end of the project. It should also include a risk analysis and a definition of a criteria for the successful completion of each deliverable. The governance process is defined, stake holders identified and reporting frequency and channels agreed. The most common tools or methodologies used in the planning stage are Business Plan and Milestones Reviews.

3) Execution and controlling

The most important issue in this phase is to ensure project activities are properly executed and controlled. During the execution phase, the planned solution is

implemented to solve the problem specified in the project's requirements. In product and system development, a design resulting in a specific set of product requirements is created. This convergence is measured by prototypes, testing, and reviews. As the execution phase progresses, groups across the organization become more deeply involved in planning for the final testing, production, and support. The most common tools or methodologies used in the execution phase are an update of Risk Analysis and Score Cards, in addition to Business Plan and Milestones Reviews.

4) Closure

In this last stage, the project manager must ensure that the project is brought to its proper completion. The closure phase is characterized by a written formal project review report containing the following components: a formal acceptance of the final product by the client, Weighted Critical Measurements (matching the initial requirements specified by the client with the final delivered product), rewarding the team, a list of lessons learned, releasing project resources, and a formal project closure notification to higher management. No special tool or methodology is needed during the closure phase.

Q2. Examine the Tools used in project planning.

Ans2. Here are examples and explanations of four commonly used tools in project planning and project management, namely: Brainstorming, Fishbone Diagrams, Critical Path Analysis Flow Diagrams, and Gantt Charts. Additionally and separately see business process modelling and quality management, which contain related tools and methods aside from the main project management models shown below.

The tools here each have their strengths and particular purposes, summarised as a basic guide in the matrix below.

Matrix key:

B = BrainstormingF = Fishbone/Ishikawa Diagrams *** -main toolC = Critical Path Analysis Flow Diagrams ** - optional/secondary toolG = Gantt Charts * -sometimes useful

B F C G

Project brainstorming and initial concepts, ideas, structures, aims, etc

*** **    

Gathering and identifying all elements, especially causal and hidden factors

* *** **  

Scheduling and timescales     ** ***

Identifying and sequencing parallel and interdependent activities and stages

*   *** *

Financials - costings, budgets, revenues, profits, variances, etc

* * ** ***

Monitoring, forecasting, reporting   * ** ***

Troubleshooting, problem identification, diagnosis and solutions

** *** ** *

'Snapshot' or 'map' overview - non-sequential, non-scheduled

** ***

Format for communications, presentations, updates, progress reports, etc

  * * ***

Brainstorming

Brainstorming is usually the first crucial creative stage of the project management and project planning process. See the brainstorming method in detail and explained separately, because it many other useful applications outside of project management.

Unlike most project management skills and methods, the first stages of the brainstorming process is ideally a free-thinking and random technique. Consequently it can be overlooked or under-utilized because it not a natural approach for many people whose mains strengths are in systems and processes. Consequently this stage of the project planning process can benefit from being facilitated by a team member able to manage such a session, specifically to help very organised people to think randomly and creatively.

Fishbone diagramsFishbone diagrams are chiefly used in quality management fault-detection, and in business process improvement, especially in manufacturing and production, but the model is also very useful in project management planning and task management generally.

Within project management fishbone diagrams are useful for early planning, notably when gathering and organising factors, for example during brainstorming.Fishbone diagrams are very good for identifying hidden factors which can be significant in enabling larger activities, resources areas, or parts of a process.

Fishbone diagrams are not good for scheduling or showing interdependent time-critical factors.

Fishbone diagrams are also called 'cause and effect diagrams' and Ishikawa diagrams, after Kaoru Ishikawa (1915-89), a Japanese professor specialising in industrial quality management and engineering who devised the technique in the 1960s.

Ishikawa's diagram became known as a fishbone diagram, obviously, because it looks like a fishbone:

A fishbone diagram has a central spine running left to right, around which is built a map of factors which contribute to the final result (or problem).

For each project the main categories of factors are identified and shown as the main 'bones' leading to the spine.

Into each category can be drawn 'primary' elements or factors (shown as P in the diagram), and into these can be drawn secondary elements or factors (shown as S). This is done for every category, and can be extended to third or fourth level factors if necessary.

The diagram above is a very simple one. Typically fishbone diagrams have six or more main bones feeding into the spine. Other main category factors can include Environment, Management, Systems, Training, Legal, etc.

The categories used in a fishbone diagram should be whatever makes sense for the project. Various standard category sets exist for different industrial applications, however it is important that your chosen structure is right for your own situation, rather than taking a standard set of category headings and hoping that it fits.

At a simple level the fishbone diagram is a very effective planning model and tool - especially for 'mapping' an entire operation.

Where a fishbone diagram is used for project planning of course the 'Effect' is shown as an aim or outcome or result, not a problem.

The 'Problem' term is used in fault diagnosis and in quality management problem-solving. Some fishbone diagrams can become very complex indeed,

which is common in specialised quality management areas, especially where systems are computerised.

This model, and the critical path analysis diagram are similar to the even more complex diagrams used on business process modelling within areas of business planning and and business process improvement.

Project critical path analysis (flow diagram or chart)'Critical Path Analysis' sounds very complicated, but it's a very logical and effective method for planning and managing complex projects. A critical path analysis is normally shown as a flow diagram, whose format is linear (organised in a line), and specifically a time-line.

Critical Path Analysis is also called Critical Path Method - it's the same thing - and the terms are commonly abbreviated, to CPA and CPM.

A commonly used tool within Critical Path Analysis is PERT (Program/Programme/Project Evaluation and Review Technique) which is a specialised method for identifying related and interdependent activities and events, especially where a big project may contain hundreds or thousands of connected elements. PERT is not normally relevant in simple projects, but any project of considerable size and complexity, particularly when timings and interdependency issues are crucial, can benefit from the detailed analysis enabled by PERT methods. PERT analysis commonly feeds into Critical Path Analysis and to other broader project management systems, such as those mentioned here.

Critical Path Analysis flow diagrams are very good for showing interdependent factors whose timings overlap or coincide. They also enable a plan to be scheduled according to a timescale. Critical Path Analysis flow diagrams also enable costings and budgeting, although not quite as easily as Gantt charts (below), and they also help planners to identify causal elements, although not quite so easily as fishbone diagrams (below).

This is how to create a Critical Path Analysis. As an example, the project is a simple one - making a fried breakfast.

First note down all the issues (resources and activities in a rough order), again for example:

Assemble crockery and utensils, assemble ingredients, prepare equipment, make toast, fry sausages and eggs, grill bacon and tomatoes, lay table, warm plates, serve.

Note that some of these activities must happen in parallel - and crucially they are interdependent. That is to say, if you tried to make a fried breakfast by doing one

task at a time, and one after the other, things would go wrong. Certain tasks must be started before others, and certain tasks must be completed in order for others to begin. The plates need to be warming while other activities are going on. The toast needs to be toasting while the sausages are frying, and at the same time the bacon and sausages are under the grill. The eggs need to be fried last. A Critical Path Analysis is a diagrammatical representation of what needs done and when. Timescales and costs can be applied to each activity and resource. Here's the Critical Path Analysis for making a fried breakfast:

This Critical Path Analysis example below shows just a few activities over a few minutes. Normal business projects would see the analysis extending several times wider than this example, and the time line would be based on weeks or months. It is possible to use MS Excel or a similar spreadsheet to create a Critical Path Analysis, which allows financial totals and time totals to be planned and tracked. Various specialised project management software enable the same thing. Beware however of spending weeks on the intricacies of computer modelling, when in the early stages especially, a carefully hand drawn diagram - which requires no computer training at all - can put 90% of the thinking and structure in place. (See the details about the most incredible planning and communications tool ever invented, and available for just a tiny fraction of the price of all the alternatives.)

project critical path analysis flow diagram example

Gantt chartsGantt Charts (commonly wrongly called gant charts) are extremely useful project management tools. The Gantt Chart is named after US engineer and consultant Henry Gantt (1861-1919) who devised the technique in the 1910s.

Gantt charts are excellent models for scheduling and for budgeting, and for reporting and presenting and communicating project plans and progress easily and quickly, but as a rule Gantt Charts are not as good as a Critical Path Analysis Flow Diagram for identifying and showing interdependent factors, or for 'mapping' a plan from and/or into all of its detailed causal or contributing elements.

You can construct a Gantt Chart using MSExcel or a similar spreadsheet. Every activity has a separate line. Create a time-line for the duration of the project (the breakfast example shows minutes, but normally you would use weeks, or for very big long-term projects, months). You can colour code the time blocks to denote type of activity (for example, intense, watching brief, directly managed, delegated and left-to-run, etc.) You can schedule review and insert break points. At the end of each line you can show as many cost columns for the activities as you need. The breakfast example shows just the capital cost of the consumable items and a revenue cost for labour and fuel. A Gantt chart like this can be used to keep track of progress for each activity and how the costs are running. You can move the time blocks around to report on actuals versus planned, and to re-schedule, and to create new plan updates. Costs columns can show plan and actuals and variances, and calculate whatever totals, averages, ratios, etc., that you need. Gantt Charts are probably the most flexible and useful of all project management tools, but remember they do not very easily or obviously show the importance and inter-dependence of related parallel activities, and they won't obviously show the necessity to complete one task before another can begin, as a Critical Path Analysis will do, so you may need both tools, especially at the planning stage, and almost certainly for large complex projects.

Gantt chart example

 A wide range of computerised systems/software now exists for project management and planning, and new methods continue to be developed. It is an area of high innovation, with lots of scope for improvement and development. I welcome suggestions of particularly good systems, especially if inexpensive or free. Many organizations develop or specify particular computerised tools, so it's a good idea to seek local relevant advice and examples of best practice before deciding the best computerised project management system(s) for your own situation.

Project planning tools naturally become used also for subsequent project reporting, presentations, etc., and you will make life easier for everyone if you use formats that people recognize and find familiar.

Q3. Describe the various steps involved in monitoring and controlling a project

Ans:- Project Monitoring and Control: Any project aimed at delivering a product or a service has to go through phases in a planned manner in order to meet the requirements. It is possible to work according to the project plan only by careful monitoring of the project progress. It requires establishing control factors to keep the project on the track of progress. The results of any stage in a project, depends on the inputs to that stage. It is therefore necessary to control all the inputs and the corresponding outputs from a stage. A project manager may use certain standard tools to keep the project on track. The project manager and the team members should be fully aware of the techniques and methods to rectify the factors influencing delay of the project and its product. The various steps involved in monitoring and controlling a project from start to end are as follows – 

Preliminary work – the team members understand the project plans, project stage schedule, progress controls, tracking schedules, summary of the stage cost and related worksheets. All the member has to understand the tolerances in any change and maintain a change control log. They must realize the need and importance of quality for which they have to follow strictly a quality review schedule and frequently discuss on the quality agendas. They must understand the stage status reports, stage end reports, stage end approval reports. 

Project Progress – The members must keep a track of the project progress and communicate the same to other related members of the project. They must monitor and control project progress, through the use of regular check points, quality charts, and statistical tables, control the quality factors which are likely to deviate from expected values as any deviation may result in changes to the stage schedule. The project manager ensures that these changes are made smoothly and organizes review meeting with the project management group. 

Stage Control – The manager must establish a project check point cycle. For this suitable stage version control procedures may be followed. The details are to be documented stage wise. Project files have to be frequently updated with suitable version control number and revision status should be maintained for each change. Team members are identified who will exercise controls at various points of the project. 

Resources – Plan the resources required for various stage of the project. Brief both the project team and the key resources about the objectives of every stage, planned activities, products, organization, metrics and project controls 

Quality Control – This is very important in any project. Quality control is possible if the project members follow the quality charts and norms very strictly.

Schedule Quality Review – It is recommended that quality review be scheduled at the beginning of the stage and also ending of every stage.

Agenda for quality review – create and distribute a quality review agenda specifying the objective, products, logistics, roles, responsibilities and time frame.Conduct quality review – the quality review is to be conducted in a structured and formal manner. Quality review should focus on product development and its quality factors. Focus on whether it meets the prescribed quality standard.

Follow up - QR complete product status revised from ‘In progresses to ‘QR Complete’. Follow up the actions planned in strict manner which ensures conformity to the standards.

Review quality control procedures – verify that the quality objectives for each product are appropriate and that all participants are satisfied both with the process and its outcome. 

The Control Of The Project Process And Project Progress Control

a) Monitor Performance: The team members log in details of actual start date, actual finish date, actual hours worked per task, estimated hours to complete the task, elapsed time in hours to compete the task, any miscellaneous costs incurred during a stage. These inputs become the base to monitor the performance of the project and its stages.

b) Update Schedule-Update the schedule for actual start date for tasks started, actual finish date for tasks finished, actual hours worked per task, latest estimated work in hours to complete the task.

Update costs - Update the stage cost summary worksheet with actual costs incurred this period, estimated remaining costs. Miscellaneous costs will be automatically updated from the scheduler, since they are calculated from actual work.

Re-plan stage schedule-Review the tracking Gantt and Cost workbook and identify any deviation from the baseline. Establish why the deviation has occurred. Refer back to the project control factors to help determine the appropriate corrective action and adjust the schedule accordingly. Determine if the stage has exceeded the progress, cost and quality tolerance levels agreed with the project management team. Review status of open issues and determine any further action required on these issues. Review the status of any outstanding quality reviews Review any new change requests.

Conduct team status review- Conduct a status meeting with the project team. Items for discussion are achievements this period planned activities that are incomplete or overdue, activities for the next period, new issues identified this period, issues closed this period, summary of results of quality reviews , summary of schedule and cost status, suggested revisions to the plan.

Create status report – The status report provides a record of current achievement and immediate expectations of the project. The status has to be effectively communicated to all interested parties.

Create Flash report - summarize the accomplishments for the month, schedule status, upcoming tasks for the month and any major issues. Distribute to the project team and project management team

Project Status Reports - As discussed earlier, the status report provides a record of current achievements and immediate expectations of the project.

- A weekly status report includes:

- Accomplishments during the period

- Items not completed during the period

- Proposed activities for the next period

- Any predicted slippage to the stage schedule, along with cause and corrective action.

- Any predicted cost overrun along with cause and corrective action.

Approvals – Project stage reviews and the decisions taken and actions planned need to be approved by the top management. The goals of such review are to improve quality by finding defects and to improve productivity by finding defects in a cost effective manner. The group review process includes several stages like planning, preparation and overview a group review meeting and rework recommendations and follow-up.

Change ControlControlling the changes in the project is possible through a proper change management process and using necessary tools for controlling the change. Change control is necessary to control the increase of work at various stages of project and to manage effectively the disruptions in the stages, if any. These factors may affect the progress of the project, resulting in deviations from the stage schedules, project and stage cost and project scope.

Changing Project Management ProcessThe processes involved in bringing about a change are the following:

i. Request for a change- Identify need for a change based on which a formal request from either a member of the project team or a client or a coordinator or Key stakeholder to make a change is to be made.

ii. Identify Alternate Solutions – Evaluate the change request and identify several alternative solutions. Assess the alternatives with respect to the functional scope, schedule, effort and cost.

iii. Decide on the Actions for the change – Present the change request, alternative solutions and recommendation to the project management team. The project management team is required to accept the recommendation, choose an alternative solution, or request further investigation.

iv. Implement change – make appropriate schedule and other project plan adjustments to accommodate the change, communicate these to team members, monitor progress and execute quality control on the changes.

Tools for Changing a process

There are various tools which can be used to bring about a change in a process. All such tools can be mainly classified into the following two types-

a) Change Management System (CMS) – It is a methodology which requires collection of all formal documented procedures, defining how project performance will be monitored and evaluated, how project plans could be updated, how various measures can be implemented to control the change process. These procedures may be unique to an organization based on their project needs. It also includes procedures to handle the changes that may be approved without prior review, so that the evolution of baseline can be documented.

b) Configuration Management (CM) – Identify the configuration items and define the naming and numbering scheme, structure the changes, define a backup procedure, and follow the methods for tracking the status of configuration items. Identify and define the responsibility and authority of the CMS.

To Understand The Post Closure Activities Along With The Way Of Reporting And Documentation 

Project Closure

Any project that is planned properly and executed as per the plan will also close successfully. For successful completion of a project every aspect of the project should be monitored and controlled.

Completion of all activities and benefits

The closure of a project may result in the following benefits –

1. It implies that on successful completion of a project, it has not drifted from its intended course and plans. Otherwise it would have resulted in a change and may also kick start another project affecting the main project.

2. The project member are acknowledged for the completion of the project, motivating them to take up more projects wherein the members would be able to confidently handle and take care of all the problems based upon their learning from earlier project.

3. It results in setting up of processes for continued development and improvement of the final product of any project forthcoming.

4. It results in setting up of improved standard process and estimating models for this type of future projects.

5. It enables resource redeployment. 

The deliverable at the end of each stage could be –

A set of specified outputs for each stage of the project New products or modified existing product Items that may be less easy to distinguish like parameter setup data

transfer, staff training etc. 

Post Implementation ReviewAfter every stage of a project is implemented, it may so happen that there could be a minor change or modification which has to be reviewed. A review may by in the following form –

a) Final product review – The product obtained after every stage must meet the requirements of that stage. If it completely meets the stated objectives then focus on the issues of maintenance of the processes and product performance. If the final product does not completely meet the objectives then identify the variations in the product and analyze the variation. Study the factors responsible for the change and evaluate each one separately.

b) Outstanding project work review – many a times it is found that there may be some item of the project which is still not in its stage finished form. It may be insignificant as it may be a byproduct of that stage not required immediately for the next stage. Then the items that are open should be resolved and necessary steps be taken to close such open items.

c) Project Review- Every aspect of a project from start to end has to be reviewed. The objectives, performance criteria, financial criteria, resource utilization, slips and gains of time, adherence to the project definition and plans have to be reviewed. All such review details and reports have to be well documented for future use.

d) Process review – Every process is important in any project. One may review the process to see if any changes can be made to improve its performance.

Q4. Explain the term ‘knowledge factor’.

Ans4.

Data base with technical or personal data in order to produce some useful information for a certain task. However, analyzing the requirements of problems CEOs have when they like to apply knowledge management as a technology leads to the fact that the terms data, information and knowledge are used synonymously, that there is usually more than one source from which the “useful information” is extracted, and that there is no architectural structure which may be used to describe neither the requirements nor the realization of the problem.

A generic architecture will be presented which is based on the semiotic paradigm of information theory. The formal framework allows an adaptation of the architecture to special realizations and as such it covers standard information systems and data base application systems. The architecture will be the kernel the metaphorical description of a knowledge factory an may be enhanced with a collection of helpful software agents.

“Knowledge management is not a product in itself, nor a solution that organizations can buy off-the-shelf or assemble from various components. It is a process implemented over a period of time, which has as much to do with human relationships as it does with business practice and information technology” (Benjamins, Fensel, Perez 1998)

DATA, INFORMATION, AND KNOWLEDGE

One major problem with knowledge management is the fact that despite of the intensive academic discourse on the terms data, information, and knowledge, in industrial practice they are used in an uncoordinated way. In the classical interpretation data is associated with syntax, information corresponds to semantic and knowledge takes the pragmatic part. I.e. data per se has no meaning and may be seen as raw material for information. Information is context sensitive and meaningful in the sense that it is interpreted data. Since context is user (application) dependant information then may be enhanced by its use, i.e. the pragmatic.

knowledge.The semiotic correspondence of data, information, and knowledge thus interpretsinformation as being the result of the transmitting knowledge and data as being the result of gathering information.

Turning the direction of reasoning leads to recent action oriented interpretations. According to (Nonaka 1994) knowledge is justified belief (i.e. information) that increases an entity’s capacity for effective action, while information is the flow of messages or meaning which may add to, restructure, or change knowledge

(Probst, Raub, Romhardt 1998). In that sense information is raw material for production of knowledge and information transforms to knowledge in the context of actions. However, it would be wrong to imply a pure set inclusion between the three, i.e. knowledge is a subset of information which is a subset of data. Information may consist of many data items and knowledge may consist of information plus action rules.

An example may be digital pictures: While on the data level only bit streams are represented the information level may contain additional format descriptions (especially those which identify the data as being a picture). Several and different information may be derived from the same data. On the knowledge level there may be semantic descriptors identifying the type of the picture (e.g. a landscape).

Now searching for landscape pictures in the data base would have no result. The information system may select pictures from the data base and only on the knowledge level a landscape painting could be distinguished from a portrait.

A GENERIC KNOWLEDGE MANAGEMENT ARCHITECTURE

Enterprises are recognizing that the enterprise knowledge management rather than information gathering and data collection is becoming one of their main business factors. Total Quality Management and Business Process Reengineering support the companies to produce better products and to become more effective. However, these activities are usually not based on the enterprise’s experience and especially they do not support the talents of their best performers. Closest to knowledge management is the use of customized OLAP (Online Analytical Processing) tools to support planning activities.

However, OLAP systems operate on large data bases tying to solve multidimensional requests for marketing, finance, and quality requests. Concerning the discussion in the last section, this means that information is generated out of data. The resulting information gives rise to (knowledge based) decisions made by human planners. In some cases expert systems are placed on top of OLAP tools in order to realize management support systems. If the expert system took care of using the companies expertise and practices, then it is a vertical knowledge management system in the sense of (Bejamins, Fensel, and Perez 1998). In the following we are interested in defining a horizontal knowledge management system which in contrast is not designed for a special business situation, but usable for different settings.

The IdeaThe aim is to develop a generic architecture for knowledge management systemsand processes which should

respect the differentiation of data, information, and knowledge

be used as a scheme to classify various types of enterprise business systems and

knowledge processes

support the flexible, though system-consistent modeling of knowledge management systems

To visualize the knowledge management architecture the picture of an onion might be taken. It consist of circles which contains either container of material or tools to produce more complex material. To be more precise, the container are data, information and knowledge bases. The tools are systems which use for instance data to produce information, like OLAP systems as discussed above. Cutting a piece from the center to the outside would then represent a specific knowledge management system, while the whole structure would represent the knowledge management facilities of an entire enterprise.

THE KNOWLEDGE FACTORY

The architecture introduced in the previous section uses objects and methods or from the view of abstract data types data and operations in the traditional sense. Since the knowledge management architecture should be used in different contexts and by various people, it would be worthwhile to extend the presentation by incorporating the “agents” who will use the tools. Hence, there is a change from the rigid architectural description to a more vivid picture which we call the “knowledge factory”. It extends the traditional view of having material and tools to work on in a natural way. Like in a factory beside the production there are the people who produce. In our scenario these are the “knowledge workers” and they will be incorporated into the framework by adding one more dimension. The following figure shows the new structure of the knowledge factory.

The Knowledge Factory Structure

The first column shows the hierarchical structure of the different types of basic objects: Knowledge bases are built on information bases which are built on data

bases. With each level are associated the operator or tools used to work on the basic objects. Connecting the two columns with the arrows mirrors the simple parts of the operator definitions, namely Local (forth and back on the same level) and Lift (diagonal up). The Combi operators are implicitly presented with the third column. It represents the worker who use the tools of the second column. So the information worker applies tools of the data level and tools of the information level in order to produce new information or knowledge units. In contrast to the first and second column there is also a cooperation between the workers. Notice that we choose a hierarchy respecting model, i.e. it is not allowed to skip a level neither vertically nor horizontally. It may be a matter of discussion whether this strict proceeding is necessary. However, theoretically all missing cases can be constructed by combining the possible activities and on the practical side it is more secure if not everyone can do everything.

Q5. What roles do cross functional teams play for project efficiency? Explain with examples.

Ans5. The most simple definition of cross-functional teams (or CFTs) is teams that are made up of people from different functional areas within a company—marketing, engineering, sales, and human resources, for example. These teams take many forms, but they are most often set up as working groups that are designed to make decisions at a lower level than is customary in a given company. They can be either a company's primary form of organizational structure, or they can exist in addition to the company's main hierarchical structure.

Cross-functional teams have become more popular in recent years for three primary reasons: they improve coordination and integration, span organizational boundaries, and reduce the production cycle time in new product development. Bringing people together from different disciplines can improve problem solving and lead to more thorough decision making. The teams foster a spirit of cooperation that can make it easier to achieve customer satisfaction and corporate goals at the same time.

Team Characteristics

LeadershipAlthough fading in popularity, matrix structured organizations still exist. In a matrix environment, team members report directly to both their functional manager as well as one or more project managers: literally a multi-manager scenario. Teams in a weak matrix environment, especially where the project manager’s influence on team members is less than the functional, are frequently mislabeled as crossfunctional teams. However, they are not truly so because of the reporting structure. This situation causes priority conflicts and animosity that result in inefficiencies to both functional groups and project teams. Teams with project managers that are lower on the organizational chart than the rest of the core members, are also frequently mislabeled as a cross-functional team. Common results include biased scope, poor implementation of project management standards, and a lack of true leadership. Just as each member of the project team is an expert in their subject matter, the project manager is the subject matter expert in regards to project management methodology, and most likely one of the members who best understands the projects interdependencies.

To be a true cross-functional team, to be efficient and meet business requirements, the project manager should lead the team and control the project lifecycle as neither a second superior nor a subordinate of the core team members.

SizeTeams need to have expertise related to the anticipated issues and tasks, and the more ideas the better. So larger teams, right? No, overwhelmingly team dynamic studies have shown larger teams produce less ideas, less productivity, decreased team member buy-in, less participation, a decrease in cost effectiveness, and less accountability. There are many reasons for these outcomes. Too much stakeholder involvement and large team size both create withdrawn members and a groupthink atmosphere. More assertive members endup making the majority of decisions; literally making the decision team smaller, reducing the cost benefit of each member, and frequently creating biased decisions.

PlanningFrequently in an effort to appease the timeline and cost expectations of business sponsors, project teams move into the design phase with inadequate requirements or even into development with deficient design specifications. The amount of rework needed, which adds to cost and timeline, will almost if not always out-weight the time and money saved on planning. The correct response to a decreased timeline is to increase the efficiency of the planning phase; the most important phase of the project. This may include a business analyst and IT Lead role to efficiently document requirements and design. But always requires the roles and responsibilities of the core project team to be clearly defined.

EstimatingA key piece of planning is the estimation of cost and timeline. It is vital to have an idea of where you are going before you can decide how you are going to get there, how long it will take, and how much it will cost; time, scope, and budget balanced justly. Estimation tools based on high-level scope and historical performance can be developed to not only get ballpark figures in the infield, but give a better start toward maintaining cost and timeline during the execution phase. Estimation tools tuned by each department provide accountability to project teams and functional departments, as well as increase project efficiency.

Project Kick-offThe invite list to project kick-off meetings should be based on both the perceived importance and true priority of the project. Projects of high importance would have large kick-offs that enable the high-level scope and timeline to be communicated throughout the organization. This not only establishes the core team as described earlier, but brings up possible issues outside the core team, allows cross-functional communication of key project issues and tasks, builds teamwork across divisions, and increases employee buy-in to the corporate strategies being met by the project.

Organizational CharacteristicsProject Management Office

A Project Management Office (PMO) is a department responsible for establishing, maintaining and enforcing project management standards throughout an organization. The PMO must have the authority to set standards via the support of executive management. Development of a true organizational PMO, regardless of the reporting department, is imperative to the implementation of effective cross-functional teams as well as the successful prioritization of projects to the overall corporate strategies. PMO Project Managers must be capable of providing expertise, vision, and leadership to project teams.

Enablement

The number one dynamic that fosters success is enabling cross-functional teams the ability to succeed or fail. Micromanagement leads to less buy-in, less creativity, and groupthink; leading many individuals to focus on making sure the project is simply not a failure and where to place blame if it does fail. Instead, management should support cross-functional project teams with the ability to fail; to have the ability to take risks, to be creative, and to develop team based solutions that increase buy-in, productivity, and success. Management that continually second guesses team decisions demonstrates a lack of trust and will decrease motivation. This enablement is not a license to proceed with reckless abandonment either. In fact, it will increase accountability.

AccountabilityThe first step of project accountability is to have agreed upon project management processes. For example, a document controls process that includes review and sign-off by key personnel at stage gates of a project. These mutually agreed to processes are under constant improvement and tuning from the feedback and review of project outcomes, resulting in further accountability. The next step is the shared accountability of project outcomes to those within the cross-functional teams and all functional areas involved; including the PMO and business areas. Often functional areas will (intentionally or not) limit project involvement or allow business decisions to be made by I.T. and then hold them responsible for any failures. It is human nature to push off accountability, and it takes effort to control the natural impulse of focus on oneself. Teamwork improvements, group rewards, enablement, and cultural shifts; do what it takes to improve accountability and at the same time maintain or increase buy in to teamwork.

Proactive VisionToo often organizations react to unfavorable situations. They experience a real loss before making any sincere change. Then, because of the loss, there is a demand for a timely and sometimes very rushed and under thought answer to

the issue. The fact of the matter is, many risks can be avoided and efficiencies can be realized when organizations proactively adapt to coming change. This requires proactive leadership with a vision of turning risks into opportunities, who are willing and able to take educated risks. Individuals, who contend for the success of the corporation and the survival of all, should be encouraged and rewarded.

Information TechnologyIt is surprising that in this technological age, some organizations still view information technology as little more than a necessary evil. Information Technology is not just a service department, a supporter of those who do the real work, but a viable part of the development and execution of the business strategy. The I.T. vs. “The Business” mentality does not stem from an inefficient IT Department, but inefficient cross functional teams and a lack of accountability on both sides of the table. Information technology takes the brunt of the blame and the solution is not for senior management to micromanage I.T., but to become more actively involved in the development of the cross-functional teams that execute business strategy.

Organizational StructureCommunication of the corporate strategy is frequently too vague and hard to quantify at both the functional and project level. Projects exist for corporate strategy to be realized; simple concept but frequently overly complicated. It is the job of management to ensure that corporate goals are communicated to the entire organization. Companies must turn strategic priorities into assigned, measurable action plans for not only project teams, but for each functional department.

RewardingOrganizations of course need to support the time and effort required for development of team skills. One frequently missed medium for accomplishing this objective is through a reward system related to project work. Rewards should be based on strategic results: both short-term and long-term successes.

ConclusionChange is the only constant, and the key variable to effectively meeting corporate objectives is proactive responses to threats and opportunities. Most organizations support the project management process, however a strong focus on project team efficiency is still a significant cultural shift, and most are reactively addressing the coming changes. With global commerce, approaching workforce shifts, industry transformations, and economic downturn, organizations must proactively create and align efficient cross functional project teams with corporate strategy to stay competitive.

Example:

Cross-functional teams are not new. Northwestern Mutual Life insurance company pioneered their use in the 1950s when the CEO of the company brought together people from the financial, investment, actuarial, and other departments to study the impact that computers would have on the business world. As a result of that first CFT, Northwestern was among the first companies in the country to create an information systems department that gave the company a large competitive advantage as computers gained in popularity. The company now relies on cross-functional teams in almost every facet of its organization. Based on success stories like this one, CFTs slowly grew in popularity throughout the 1960s and 1970s before exploding in popularity in the 1980s when faster production time and increased organizational performance became critical in almost every industry.

Cross-functional teams are similar to conventional work teams, but they differ in several important ways. First, they are usually composed of members who have competing loyalties and obligations to their primary subunit within the company (for example, a marketing person serving on a cross-functional team has strong ties to his or her home department that may conflict with the role he or she is being asked to play on the CFT). Second, in companies where CFTs are being used on a part-time basis as opposed to a permanent organizational structure, they are often temporary groups organized for one important purpose, which means group members are often under considerable pressure. On these temporary teams, the early development of stable and effective group interaction is imperative. Finally, CFTs are often held to higher performance standards than conventional teams. Not only are they expected to perform a task or produce a product, but they are also expected to reduce cycle time, create knowledge about the CFT process, and disseminate that knowledge throughout the organization.

For cross-functional teams to succeed, several factors have been identified that are imperative:

Team members must be open-minded and highly motivated. Team members must come from the correct functional areas. A strong team leader with excellent communication skills and a position of

authority is needed. The team must have both the authority and the accountability to

accomplish the mission it has been given. Management must provide adequate resources and support for the team,

both moral and financial. Adequate communications must exist.

Without any one of these elements, any cross-functional team will be fighting an uphill battle to succeed.

Q6. Do core groups enhance the performance of projects?

Ans6. The scope of the joint project will be the development of a new video coding standard and the assessment of its performance at the completion of the work using formal subjective testing procedures.

The intent is that the ITU-T Recommendation and ISO/IEC International Standard be technically aligned, fully interoperable with each other for all of the video codec’s conformance points specified during the term of this joint work, and offer the best possible technical performance under the practical constraints of being implementable on various platforms and for various applications enabled by the relevant ITU-T Recommendations and ISO/IEC International Standards. Common text will not be used in the interest of minimising co-ordination overhead.

Joint GroupThe work of the project will be conducted by a jointly-constituted experts group which will be known as the Joint Video Team (“JVT”).JVT will operate as a joint group under the ordinary policies and procedures of both organisations. In the event of differences between policies of ISO/IEC and ITU-T not covered by these ToR, the JVT Rapporteur|Chair will decide the issue, based on the consensus of the experts and if necessary in consultation with the parent bodies, in the best interests of standardization.

Deliverables of the Joint ProjectThe deliverables are a new video codec informally called the JVT codec, to be approved by ITU as an ITU-T Recommendation and by ISO/IEC as an International Standard. These deliverables will be developed with requirements as described.

DissolutionThe joint group will dissolve when the approval process for the new Recommendation and International Standard in both organisations is completed. The joint group may also be dissolved at the initiative of one or both the parent bodies if unexpected conditions materialise that require one or both of the parent bodies to take this action.

Potential new joint work beyond the duration of this project (e.g., extensions, corrigenda, amendments, etc.) will require the agreement of the two parent bodies. It is anticipated that such agreement would be reached in case the need for a corrigendum is discovered.

MeetingsJVT meeting venue and dates will be proposed by the JVT Rapporteur/Chair, and authorized by the parent bodies under the customary practices of both organisations.

JVT meetings will be held as an entity that is separate from the two parent bodies, and will operate under rules set forth in Annex 3 of this ToR.

The meeting dates and locations should be co-ordinated with those of meetings of the ITU-T SG16 and ISO/IEC JTC 1/SC 29/WG 11 (e.g. on an alternating basis if feasible for the progress of the project) in order to reduce the amount of travelling for participants and will be preferably co-located with a parent body meeting and held immediately before, during, or after the corresponding SG16 meetings or during the corresponding WG 11 meeting dates.

ManagementThe management of the JVT will consist of a jointly-appointed Rapporteur/Chair and two Associate Rapporteurs/Co-Chairs (one each as appointed from the parent bodies with joint consent), reporting to the parent bodies. Changes in the management team must be agreed by the two parent bodies.

Documents and ContributionsJVT will maintain a document registry and electronic distribution archive. The registry and archive will be linked to both the ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG 11 web sites. Any document from a participant in the meeting should be available to all the participants before the meeting through the use of electronic document handling. A registration and uploading deadline several days in advance of the start of the meeting will be announced for each meeting. A “late, unannounced” document hand-carried to the meeting should be accepted only with the consensus of the meeting participants. This policy will be stated in the invitation letter that is provided for every meeting to both organisations.

All documents and contributions will be in electronic form (preferably MS Word). In order to facilitate cross-organisational communication, all input and output documents will be public unless the contributor of an input document indicates otherwise. In that circumstance, the document will be accessible only through a private, password-protected site accessible only to ITU/ISO/IEC members and invited experts regularly attending the JVT meetings. Invited experts not regularly attending JVT meetings may be given access to such documents upon approval of its author.

Working MethodsGeneral Policies and ProceduresAll group decisions will be made by the consensus of the JVT experts as determined by the JVT Chair|Rapporteur. All contributions related to the joint

project must be addressed to JVT for the duration of the joint project, rather than to the individual parent bodies. Additionally, these may also be submitted to anyof the parent bodies (according to their specific document submission procedures), if the author of the contribution so determines.

Working relationship between JVT and the parent bodiesThe parent bodies may like to provide inputs (either in the form of written documents or by holding meetings with the appropriate parent body sub-groups) on the work carried out by JVT. A non-exhaustive list includes:

1. New requirements dictated by new applications that may be served by the new video coding

2. Complexity analysis of the solutions being adopted3. Partitioning of the video coding tool space in profiles4. Definition of levels5. Requirements for the design of verification tests6. Profiles to be tested in the verification tests.

JVT will consider the inclusion of these inputs in its work, also considering the impact of such inputs in the other parent body’s requirements. JVT will report back to the originating organisation on the action taken.

Document ControlJVT will maintain a single master draft document and a single reference software codebase for the developing video coding standard, each under the control of a single editor, appointed by the JVT

Chair|Rapporteur with the consensus of the experts. The document and codebase will contain the exact text to be submitted to the parent bodies for approval.

Meeting ReportsA meeting report will be provided by the JVT management shortly after the conclusion of each meeting and will be submitted to ITU TSB and ISO/IEC JTC 1/SC 29/WG 11, posted on the group’s FTP sites, and distributed to the experts.

The report should include:

• Dates and venue• Chairpersons/Rapporteurs of the meeting• Attendance list with affiliation• Agenda of the meeting• List of documents considered with source• Summary of results and an outline of any outstanding issues or resolutions• Any outgoing liaison statements/communications sent to other organisations• Future activities

Promotion and Public Relations ActivitiesAny public relations or promotional activities regarding the joint group, its project, and its results and deliverables will be approved by the JVT Chair/Rapporteur with the consensus of the experts. All promotion and public relations activities will undergo review and consent by both parent bodies (VCEG and MPEG, if necessary in consultation with higher-level committee management).

\

SMUASSIGNMENT

SEMESTER – 2MBO033

Project managementSet-2

SUBMITTED BY: Gyanendra kumar

MBA ROLL NO:-

520941253

Q1. Examine briefly the seven steps of performance management of projects

Ans.  Performance Management   – The professional manager not only ensures that his performance is at peak all times, but motivates his entire team to do it. This comes by appreciation and encouragement. If there any shortfalls he arranges for training them so that their performance improves. Thus the team members know that they are expected to perform, that they get help to do so and their effort is recognized. This is the simple path of performance management. The following seven step model will be useful: 

1. Objectives/Performance standards are set.2. These are communicated to the employees.3. Review/monitor the above.4. Check actual performance Vs. Standards set.5. Identify gaps.6. Jointly decide on corrective action, if needed.7. Reset objectives for next period

 

1. Objectives/Performance Standards Are Set 

1. To mange any criterion, it is necessary to measure the factors that were responsible for ‘what is’. The quality of the input, their quantity and their intended usage. Then measures of the utilization- the processes used, their suitability, and the difficulties faced in utilization and how they were resolved. Then the outcomes – are they as they were expected. Performance closer or beyond expectation is the degree of quality. For every employee the level of achievement is set in terms of quantities and extent to which the performance approached the standard. This is the basis for evaluating performance.

 2. These are communicated to the employees – This procedure ensures that they know what is expected of them and help them to adjust their activities in such a way as to meet them. This enables them to seek help, consult their colleagues or bosses, and learn– so that they will meet the expectations. It is possible that some objectives cannot be met at all. The communication to his boss, may help in reallocating the job, so that there will be no hiccups at the end of the period.

3. Review/monitor the above – Review helps in resetting the goals when they cannot be achieved for various reasons – shortage of resources, time etc. By monitoring, the shortfalls can be made up with the allocation of extra resources, or even diverting the operation.

4. Check actual performance Vs. Standards set – This is the evaluation phase. Comparison on every detail is made. Differences are recorded. Particular areas are chosen for improvement.

5. Identify gaps – Gaps mean the shortfall in performance standards. The immediate supervisor is also involved. The extent to which they affect the functions of the job itself are identified

6. Jointly decide on corrective action, if needed – There is a possibility that the performance has exceeded the set standards. But if performance is not good – the reasons and extent having been identified, the course of action for effecting corrections are decided. Giving extra responsibilities, training, relocation is considered.

7. Reset objectives for next period – The targets are revised either upward or downward depending on the conclusion of the appraisal process.

Identification with the organisation – A sense of pride and belonging goes with the “ownership” of the job, the project, team members and organisation. This is brought about by the culture and communication system in the organisation. Information sharing brings in trust and promotes belongingness. The tendency seen is that most managers strongly identify with their own departments, units or divisions and they lack a sense of organisation.

In the light of increased competition and ever changing strategies to develop business orientation, which in effect means every manager should be aware of the company’s plans, products and policies. An obvious corollary to this is that the organization’s communication policy too should be conducive to such information sharing. Today, many organizations are using interventions such as team building, survey feedback, and other activities, to ensure that employees build up a strong sense of identity and pride in the organisation they work for.

Empowering employees: The professional manager should possess the ability to empower his employees down the line. Many managers are not even ready to delegate their authority to subordinates and end up only delegating responsibility. Empowerment is the process by which employees are encouraged to take decisions pertaining to their area of work. Empowerment ensures execution of his duties. This leads employees developing a sense of pride in their jobs. But managers often hesitate to empower their subordinates as they feel insecure and show a sense of uncertainty. The professional manager practices empowerment and encourages employees to grow and develop in their positions.

 Coping with changes: It is often said – ‘The only constant in this world is change’. A professional manager has the ability and capacity to cope with change. He accepts the fact that change is inevitable and is ready to implement change at the workplace. To implement change successfully, it is essential that employees are involved in the implementation of change. Further the positive and negative consequences of change need to be discussed and understood before implementation. Thus a professional manager has the attitude to accept change as a way of life and takes it in his stride

Q2. Is substitution necessary?

Ans. Technology Substitution

Technology substitution is based on the fact that several alternate technological routes are available to create a particular device. These alternate routes are normally hidden behind the commonly known processes, in different forms. Identification of these hidden technologies will open up opportunities for technology substitution. Some of the examples of technology substitution are in the fields of Aerospace, Automobile, water storage dams, etc. We give just two examples from the aerospace industry. In recent years, because of the versatility of software programmes which can be written to simulate a variety of operating conditions, a great amount of work is going on – both in terms of variety and depth.

(a) Substitution of experimentation – Tests is conducted to certify the performance parameters of Aerospace Systems Wind tunnel testing has been conducted for a long time. In this process wind is blows at speeds at which the aircraft is expected to be flying, and the aircraft engine, wings, tails and other parts the simulation is conducted and readings recorded for analyses. Now with the use of computer systems this costly procedure can be substituted by Computational Fluid Dynamics. The flight testing can be greatly reduced by the use of digital and hardware – in – loop simulation.

(b) Substitution or enhancement of Hardware with Software – for example, in the case of an Inertial Navigation System, the Gyro Stabilized Platforms can be replaced by the strap down systems using On-Board computer and software improving the accuracy of navigation systems.

In the same way, a wide variety of subsystems for commercial and industrial uses have many components which are used by the manufacturing organizations. It is well known that many of them find military applications and are made especially for them. However, these are superior than those used for industrial purposes for obvious reasons. With some minor improvements they can be used for superior performance when such requirement can bear a little higher cost.

Q3. In what ways can an ERP package be utilized? Explain

Ans:- The Role of Effective Data Management in the Success of Project Management:

Data management consists in conducting activities which facilitate in acquiring data, processing it and distributing it. Acquisition of data is the primary function. Data to be useful should have three important characteristics – relevancy, sufficiency and timeliness. Management of acquisition lies in ensuring that these are satisfied – before they are stored for processing and decisions taken on the analyses. We will have data about customers, suppliers, market conditions, new technology, opportunities, human resources, economic activities, government regulations, political upheavals, – all of which affect the way we function. Most of the data go on changing because the aforesaid sources have uncertainty inherent in them. So updating data is a very important aspect of their management.

Storing what is relevant in a form that is available to concerned persons is also important. When a project is underway dataflow from all members of the team will be flowing with the progress of activities, shortfalls they are suffering from seeking instructions, reporting on actions taken them. He will have to analyse them, discover further data from other sources and see how he can use them and take decisions. Many times he will have to inform and seek sanction from top management. The management will have to study the impact on the overall organizational goals and strategies and convey their decisions to thee manager for implementation. The appropriateness of decisions taken given a set of circumstances and data form the knowledge base for the organisation. BOM – Bill of Materials is a very important document in Project Management.

It contains details about all materials that go into the project at various stages and has to be continuously updated as all members of the project depend upon it for providing materials for their apportioned areas of execution. Since information is shared by all members, there is an opportunity for utilizing some of them when others do not need them. To ascertain availability at some future point of time, information about orders placed, backlogs, lead times are important for all the members. A proper MIS will take care of all these aspects. ERP packages help in integrating data from all sources and present them to individual members in the way they require. When all these are done efficiently the project will have no hold ups an assure success.

 

Q4. How is a risk analysis done?

Ans:- Learning Objective-2 : Analyze The Risk And The Steps Necessary To Manage The Risks 

Risk AnalysisThe first step in risk analysis is to make each risk item more specific. Risks such as, “Lack of Management buy-in,” and “people might leave,” are a little ambiguous. In these cases the group might decide to split the risk into smaller specific risks, such as, “manager Jane decides that the project is not beneficial,” “Database expert might leave,” and “Webmaster might get pulled off the project.”

The next step is to set priorities and determine where to focus risk mitigation efforts. Some of the identified risks are unlikely to occur, and others might not be serious enough to worry about. During the analysis, discuss with the team members, each risk item to understand how devastating it would be if it did occur, and how likely it is to occur. For example, if you had a risk of a key person leaving, you might decide that it would have a large impact on the project, but that it is not very likely.

In the process below, we have the group agree on how likely it thinks each risk item is to occur, using a simple scale from 1 to 10 (where 1 is very unlikely and 10 is very likely). The group then rates how serious the impact would be if the risk did occur, using a simple scale from 1 to 10 (where 1 is little impact and 10 is very large). To use this numbering scheme, first pick out the items that rate 1 and 10, respectively. Then rate the other items relative to these boundaries. To determine the priority of each risk item, calculate the product of the two values, likelihood and impact. This priority scheme helps push the big risks to the top of the list, and the small risks to the bottom. It is a usual practice to analyze risk either by sensitivity analysis or by probabilistic analysis.

In sensitivity analysis a study is done to analyse the changes in the variable values because of a change in one or more of the decision criteria.

In the probability analysis, the frequency of a particular event occurring is determined, based on which it average weighted average value is calculated.

Each outcome of an event resulting in a risk situation in a risk analysis process is expressed as a probability. Risk analysis can be performed by calculating the expected value of each alternative and selecting the best alternative.

Ex : Now that the group has assigned a priority to each risk, it is ready to select the items to mange. Some projects select a subset to take action upon, while others choose to work on all of the items. To get started, you might select the top 3 risks, or the top 20%, based on the priority calculation.

Learning Objective-3 : To Understand The Processes Needed To Review A Risk Situation And The Risk And Its Causes 

Risk Management PlanningThere are two things one can do to manage risk. The first is to take action to reduce (or partially reduce) the likelihood of the risk occurring. For example, some project that work on process improvement make their deadlines earlier and increases their efforts to minimize the likelihood of team members being pulled off the project due to changing organizational priorities. In a software product, a critical feature might be developed first and tested early.

Second, we can take action to reduce the impact if the risk does occur. Sometimes this is an action taken prior to the crisis, such as the creation of a simulator to use for testing if the hardware is late. At other times, it is a simple backup plan, such as running a night shift to share hardware.

For the potential loss of a key person, for example, we might do two things:

Plan to reduce the impact by making sure other people become familiar with that person’s work, or reduce the likelihood of attrition by giving the person a raise, or by providing day-care.

Q5. Why is support software required in project management process? Explain some of them

Ans:- Support Software 

Having learnt the basics of Application software, students would have a fair idea of how & to what extent PM Processes could be automated. However, the challenge of “making things work” remains unchanged. While Software Vendors are confident of “making it work”, two yawning gaps still remain – Business Processes which are not covered in such Software & Integration of Multi vendor supported software applications.

The Enterprise is normally in a dilemma – whether to look at the same vendors to support such customization or not. This normally works out too expensive for their comfort or within their tight budgets. Several Software Vendors have seized the opportunity with offerings that substantially fill these gaps effectively at a fraction of the costs quoted by the major vendors. The other carrot which these vendors offer is a unilateral transfer of the facility to customize them which is seen as a huge advantage. The various support software that may be used for managing projects are:

 

        ARROW

        FEDORA

        VITAL

        PILIN

        MS EXCHANGE SERVER 2003

The ARROW Project 

It is a consortia of institutional repository solution, combining Open source and proprietary Software

Why did we want a repository?

Provides a platform for promoting research output in the ARROW context, Safeguards digital information, Gathers an institution’s research output into one place, Provides consistent ways of finding similar objects, allows information to be preserved over the long term, allows information from many repositories to be

gathered and searched in one step, enables resources to be shared, while respecting access constraints (when software allows access controls), enables effective communication and collaboration between researchers

The project ARROW?“The ARROW project will identify and test software or solutions to support best practice institutional digital repositories comprising e-prints, digital theses and electronic publishing.”

What did the ARROW project set out to achieve?It provides solution for storing any digital output. Their Initial focus was on print equivalents – thesis, journal articles, etc. It provided solution that could offer on-going technical support and development past the end of the funding period of the project.

What is ARROW now?A development project Combining Open Source and proprietary software: Fedora, VITAL, Open Journal Services (OJS). It is NOT a centralized or hosting solution. Every member has their own hardware and software

Why Fedora?ARROW wanted a robust, well architected underlying platform, a flexible object-oriented data model to be able to have persistent identifiers down to the level of individual data streams. It accommodates the content model to be able to be version independent.

ARROW and FedoraSince the beginning of the project ARROW has worked actively and closely with Fedora and the Fedora Community, ARROW project Technical Architect is a member of Fedora Advisory Board. ARROW Project Technical Architect sits on Fedora Development Group

This is reinforced by VTLS Inc. VTLS President is a member of Fedora Advisory Board and VITAL Lead Developer sits on Fedora Development Group

VITALWhat is VITAL?

ARROW specified software created and fully supported by VTLS Inc. built on top of Fedora that currently provides:

VITAL Manager VITAL Portal VITAL Access Portal VALET – Web Self-Submission Tool Batch Loader Tool Handles Server (CNRI)

Google Indexing and Exposure SRU / SRW Support VITAL architecture overview

 

Creative development of ARROW institutional repositories Inclusion of multimedia and creative works produced in Australian

universities. To date have had limited exposure nationally or internationally. Addition of annotation capability Inclusion of datasets and other research output not easily provided in any

other publishing channel. In conjunction with the DART (ARCHER) Project. Exploration of the research-teaching nexus tools that will allow value

added services for repositories. Integration with or development of new tools that will allow value added

services for repositories. For instance the creation of e-portfolios or CVs of research output of

individual academics. 

PILIN – Persistent Identifiers and Linking InfrastructureGrowing realization that sustainable identifier infrastructure is required to deal with the vast amount of digital assets being produced and stored within universities. PILIN is a particular challenge for e-research communities where massive amounts of data are being generated without any means of managing this data over any length of time. The broad objectives are to:

1. Support adoption and use of persistent identifiers and shared persistent identifier management services by the project stakeholders.

2. Plan for a sustainable, share identifier management infrastructure that enables persistence of identifiers and associated services over archival lengths of time

3. Deploying a Worldwide Site Consolidation Solution for Exchange Server 2003 at Microsoft

4. Picture5. Using Microsoft Exchange Server 2003 to consolidate more than 70

messaging sites worldwide into seven physical locations 

Microsoft Model Enterprises (MME)Objectives

Maximizing the number of management tasks performed centrally Decrease the number of sites through the consolidation of the smaller

locations into a smaller number of RDCs Reducing the total number of infrastructure and application servers

Standardizing infrastructure and devices worldwide 

Solution

Consolidation of 75 tail sites into 6 regional data centers (RDCs) using local storage area networks (SANs)

Key Focus Areas Proactive, detailed monitoring and analysis of WAN bandwidth utilization

and latency Effective but flexible approach to project planning, scheduling, and cross-

group coordination Coordination and control of deployment of successive pre-release

versions of Office System 2003 (including Outlook 2003) 

Business Benefits

Four percent overall direct cost savings Key enabler of the Microsoft ME initiative which through fiscal year 2003

has produced USD $23.2 million in overall consolidation savings including USE

IT Benefits

Improved server utilization Improved server management Strengthened security Increased reliability.

Q6. Show your understanding of the use of MS project software

Ans-

Project Management using Software 

The Microsoft Project family of products offers tools to work on a Project from management point of view. Microsoft Project is designed for people who manage projects independently and don’t require the capability to manage resources from a central repository. Microsoft has a team project management solution that enables project managers and their teams to collaborate on projects.

After creating a fairly complete final project plan it is a good idea to create a baseline to compare the original project plan with actual events and achievements.

Reviewing the BaselineThe Baseline created can be used to compare the original project plan with actual events and achievements. This will display the days required for each task and project phase. For actual operating instruction please refer the Microsoft Project User Handbook.

Tracking ProgressAfter creating a baseline, if the project has begun, it is necessary to enter actual dates that tasks are being completed and the resource utilization used to complete them. Again review different views and the cost and summary tables before proceeding to the next section. Return to the Entry view of the Gantt chart before proceeding.

Balancing WorkloadsAt times people and equipment can become assigned more work than they can complete in normal working hours. This is called over allocation. Project can test for this condition and reschedule (or level) their workload to accommodate completing tasks during a normal day.

 Monitoring VariancesAfter a baseline has been established and the project has begun, it is desirable to determine if tasks are being accomplished on time and /or if cost over runs are occurring. 

Creating ReportsProject has many different built-in reports and has the capability building custom reports and exporting data to other MS Office applications for integration into other reporting venues.