mb033-project management [solved] set 1

8/9/2019 MB033-Project Management [SOLVED] SET 1

1/27

Master of Business Administration- MBA Semester 2MB0049 Project Management - 4 Credits

(Book ID :)

Assignment Set- 1 (60 Marks)

Note: Each question carries 10 Marks. Answer all the questions.

Q1. Explain briefly the life cycle of a project.

Ans1.

The Project Life Cycle refers to a logical sequence of activities to accomplish the projectsgoals or objectives. Regardless of scope or complexity, any project goes through a series of stages duringits life. There is first anInitiation 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, anExecution phase, in which the project plan is executed, and lastly a Closure or Exit phase, that marks thecompletion of the project. Project activities must be grouped into phases because by doing so, the projectmanager and the core team can efficiently plan and organize resources for each activity, and alsoobjectively measure achievement of goals and justify their decisions to move ahead, correct, or terminate. Itis of great importance to organize project phases into industry-specific project cycles. Why? Not onlybecause each industry sector involves specific requirements, tasks, and procedures when it comes toprojects, but also because different industry sectors have different needs for life cycle managementmethodology. And paying close attention to such details is the difference between doing things well andexcelling as project managers.

Diverse project management tools and methodologies prevail in the different project cycle phases. Lets take

a closer look at whats important in each one of these stages:

1)InitiationIn this first stage, the scope of the project is defined along with the approach to be taken to deliver thedesired outputs. The project manager is appointed and in turn, he selects the team members based on theirskills and experience. The most common tools or methodologies used in the initiation stage are ProjectCharter, Business Plan, Project Framework (or Overview), Business Case Justification, and MilestonesReviews.
http://www.visitask.com/project-initiation-phase.asphttp://www.visitask.com/project-initiation-phase.asphttp://www.visitask.com/project-management-planning-phase.asphttp://www.visitask.com/project-initiation-phase.asphttp://www.visitask.com/project-management-planning-phase.asp


2/27

2)PlanningThe second phase should include a detailed identification and assignment of each task until the end of theproject. It should also include a risk analysis and a definition of a criteria for the successful completion ofeach 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 Planand Milestones Reviews.

3)Execution and controllingThe 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 theproject's requirements. In product and system development, a design resulting in a specific set of productrequirements is created. This convergence is measured by prototypes, testing, and reviews. As theexecution phase progresses, groups across the organization become more deeply involved in planning forthe final testing, production, and support. The most common tools or methodologies used in the executionphase are an update of Risk Analysis and Score Cards, in addition to Business Plan and MilestonesReviews.

4)ClosureIn this last stage, the project manager must ensure that the project is brought to its proper completion. Theclosure 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 initialrequirements specified by the client with the final delivered product), rewarding the team, a list of lessonslearned, releasing project resources, and a formal project closure notification to higher management. Nospecial 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 projectplanning and project management, namely: Brainstorming, Fishbone Diagrams,Critical Path Analysis Flow Diagrams, and Gantt Charts. Additionally andseparately see business process modelling and quality management, whichcontain related tools and methods aside from the main project managementmodels shown below.The tools here each have their strengths and particular purposes, summarised asa 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
http://www.visitask.com/project-management-execution-phase.asphttp://www.visitask.com/project-management-execution-phase.asphttp://www.visitask.com/closure-phase.asphttp://www.visitask.com/closure-phase.asphttp://www.businessballs.com/business-process-modelling.htmhttp://www.businessballs.com/qualitymanagement.htmhttp://www.businessballs.com/project.htm#brainstorming%23brainstorminghttp://www.businessballs.com/project.htm#fishbone-diagrams%23fishbone-diagramshttp://www.businessballs.com/project.htm#fishbone-diagrams%23fishbone-diagramshttp://www.businessballs.com/project.htm#critical-path-analysis%23critical-path-analysishttp://www.businessballs.com/project.htm#gantt-charts%23gantt-chartshttp://www.visitask.com/project-management-execution-phase.asphttp://www.visitask.com/closure-phase.asphttp://www.businessballs.com/business-process-modelling.htmhttp://www.businessballs.com/qualitymanagement.htmhttp://www.businessballs.com/project.htm#brainstorming%23brainstorminghttp://www.businessballs.com/project.htm#fishbone-diagrams%23fishbone-diagramshttp://www.businessballs.com/project.htm#critical-path-analysis%23critical-path-analysishttp://www.businessballs.com/project.htm#gantt-charts%23gantt-charts


3/27

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

*** **

Gathering and identifying all elements, especially causaland hidden factors

* *** **

Scheduling and timescales ** ***

Identifying and sequencing parallel and interdependentactivities and stages

* *** *

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

* * ** ***

Monitoring, forecasting, reporting * ** ***

Troubleshooting, problem identification, diagnosis andsolutions

** *** ** *

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

** ***

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

* * ***

brainstormingBrainstorming is usually the first crucial creative stage of the project managementand project planning process. See the brainstorming method in detail andexplained separately, because it many other useful applications outside of projectmanagement.Unlike most project management skills and methods, the first stages of thebrainstorming process is ideally a free-thinking and random technique.Consequently it can be overlooked or under-utilized because it not a naturalapproach for many people whose mains strengths are in systems and processes.Consequently this stage of the project planning process can benefit from beingfacilitated by a team member able to manage such a session, specifically to helpvery organised people to think randomly and creatively.fishbone diagramsFishbone diagrams are chiefly used in quality management fault-detection, and inbusiness process improvement, especially in manufacturing and production, butthe 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 besignificant in enabling larger activities, resources areas, or parts of a process.Fishbone diagrams are not good for scheduling or showing interdependent time-critical factors.
http://www.businessballs.com/brainstorming.htmhttp://www.businessballs.com/brainstorming.htm


4/27

Fishbone diagrams are also called 'cause and effect diagrams' and Ishikawadiagrams, after Kaoru Ishikawa (1915-89), a Japanese professor specialising inindustrial quality management and engineering who devised the technique in the1960s.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 builta map of factors which contribute to the final result (or problem).For each project the main categories of factors are identified and shown as themain '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 asS). This is done for every category, and can be extended to third or fourth levelfactors if necessary.

The diagram above is a very simple one. Typically fishbone diagrams have six ormore main bones feeding into the spine. Other main category factors can includeEnvironment, Management, Systems, Training, Legal, etc.The categories used in a fishbone diagram should be whatever makes sense forthe project. Various standard category sets exist for different industrialapplications, however it is important that your chosen structure is right for yourown 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' isshown as an aim or outcome or result, not a problem.The 'Problem' term is used in fault diagnosis and in quality managementproblem-solving. Some fishbone diagrams can become very complex indeed,


5/27

which is common in specialised quality management areas, especially wheresystems are computerised.This model, and the critical path analysis diagram are similar to the even morecomplex diagrams used on business process modellingwithin areas of businessplanning 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 andeffective method for planning and managing complex projects. A critical pathanalysis is normally shown as a flow diagram, whose format is linear (organisedin 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 aspecialised method for identifying related and interdependent activities andevents, especially where a big project may contain hundreds or thousands of

connected elements. PERT is not normally relevant in simple projects, but anyproject of considerable size and complexity, particularly when timings andinterdependency issues are crucial, can benefit from the detailed analysisenabled by PERT methods. PERT analysis commonly feeds into Critical PathAnalysis and to other broader project management systems, such as thosementioned here.Critical Path Analysis flow diagrams are very good for showing interdependentfactors whose timings overlap or coincide. They also enable a plan to bescheduled according to a timescale. Critical Path Analysis flow diagrams alsoenable 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 asimple one - making a fried breakfast.First note down all the issues (resources and activities in a rough order), againfor example:Assemble crockery and utensils, assemble ingredients, prepare equipment,make toast, fry sausages and eggs, grill bacon and tomatoes, lay table, warmplates, serve.Note that some of these activities must happen in parallel - and crucially they areinterdependent. That is to say, if you tried to make a fried breakfast by doing onetask at a time, and one after the other, things would go wrong. Certain tasks mustbe started before others, and certain tasks must be completed in order for othersto begin. The plates need to be warming while other activities are going on. Thetoast needs to be toasting while the sausages are frying, and at the same timethe bacon and sausages are under the grill. The eggs need to be fried last. ACritical Path Analysis is a diagrammatical representation of what needs done andwhen. Timescales and costs can be applied to each activity and resource. Here'sthe Critical Path Analysis for making a fried breakfast:
http://www.businessballs.com/business-process-modelling.htmhttp://www.businessballs.com/business-process-modelling.htmhttp://www.businessballs.com/acronyms.htm#PERT-acronymhttp://www.businessballs.com/business-process-modelling.htmhttp://www.businessballs.com/acronyms.htm#PERT-acronym


6/27

This Critical Path Analysis example below shows just a few activities over a fewminutes. Normal business projects would see the analysis extending severaltimes wider than this example, and the time line would be based on weeks ormonths. It is possible to use MS Excel or a similar spreadsheet to create aCritical Path Analysis, which allows financial totals and time totals to be planned

and tracked. Various specialised project management software enable the samething. Beware however of spending weeks on the intricacies of computermodelling, when in the early stages especially, a carefully hand drawn diagram -which requires no computer training at all - can put 90% of the thinking andstructure in place. (See the details about the most incredible planning andcommunications tool ever invented, and available for just a tiny fraction of theprice of all the alternatives.)project critical path analysis flow diagram example

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

Gantt charts are excellent models for scheduling and for budgeting, and forreporting and presenting and communicating project plans and progress easilyand quickly, but as a rule Gantt Charts are not as good as a Critical PathAnalysis Flow Diagram for identifying and showing interdependent factors, or for'mapping' a plan from and/or into all of its detailed causal or contributingelements.You can construct a Gantt Chart using MSExcel or a similar spreadsheet. Everyactivity has a separate line. Create a time-line for the duration of the project (the
http://www.businessballs.com/games.htm#incredible%20planning%20toolhttp://www.businessballs.com/games.htm#incredible%20planning%20toolhttp://www.businessballs.com/games.htm#incredible%20planning%20toolhttp://www.businessballs.com/games.htm#incredible%20planning%20tool


7/27

breakfast example shows minutes, but normally you would use weeks, or for verybig long-term projects, months). You can colour code the time blocks to denotetype of activity (for example, intense, watching brief, directly managed, delegatedand left-to-run, etc.) You can schedule review and insert break points. At the endof 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 arevenue cost for labour and fuel. A Gantt chart like this can be used to keep trackof progress for each activity and how the costs are running. You can move thetime blocks around to report on actuals versus planned, and to re-schedule, andto create new plan updates. Costs columns can show plan and actuals andvariances, and calculate whatever totals, averages, ratios, etc., that you need.Gantt Charts are probably the most flexible and useful of all project managementtools, but remember they do not very easily or obviously show the importanceand inter-dependence of related parallel activities, and they won't obviously showthe necessity to complete one task before another can begin, as a Critical PathAnalysis 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 projectmanagement and planning, and new methods continue to be developed. It is anarea of high innovation, with lots of scope for improvement and development. I

welcome suggestions of particularly good systems, especially if inexpensive orfree. Many organizations develop or specify particular computerised tools, so it'sa good idea to seek local relevant advice and examples of best practice beforedeciding the best computerised project management system(s) for your ownsituation.Project planning tools naturally become used also for subsequent projectreporting, presentations, etc., and you will make life easier for everyone if youuse formats that people recognize and find familiar.
http://www.businessballs.com/contactus.htmhttp://www.businessballs.com/contactus.htm


8/27

Q3. Describe the various steps involved in monitoring and controlling a projectAns:- Project Monitoring and ControlAny project aimed at delivering a product or a service has to go through phasesin a planned manner in order to meet the requirements. It is possible to workaccording 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 istherefore necessary to control all the inputs and the corresponding outputs froma stage. A project manager may use certain standard tools to keep the project ontrack. The project manager and the team members should be fully aware of thetechniques and methods to rectify the factors influencing delay of the project andits product. The various steps involved in monitoring and controlling a projectfrom start to end are as follows

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

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

Stage Control The manager must establish a project check point cycle. Forthis suitable stage version control procedures may be followed. The details are to


9/27

be documented stage wise. Project files have to be frequently updated withsuitable version control number and revision status should be maintained foreach change. Team members are identified who will exercise controls at variouspoints of the project.

Resources Plan the resources required for various stage of the project. Briefboth 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 possibleif the project members follow the quality charts and norms very strictly.Schedule Quality Review It is recommended that quality review be scheduledat 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 structuredand formal manner. Quality review should focus on product development and itsquality factors. Focus on whether it meets the prescribed quality standard.Follow up - QR complete product status revised from In progresses to QRComplete. Follow up the actions planned in strict manner which ensuresconformity to the standards.Review quality control procedures verify that the quality objectives for eachproduct are appropriate and that all participants are satisfied both with theprocess and its outcome.

The Control Of The Project Process AndProject Progress Controla) Monitor Performance: The team members log in details of actual start date,actual finish date, actual hours worked per task, estimated hours to complete thetask, elapsed time in hours to compete the task, any miscellaneous costsincurred during a stage. These inputs become the base to monitor theperformance 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, latestestimated work in hours to complete the task.

Update costs - Update the stage cost summary worksheet with actualcosts incurred this period, estimated remaining costs. Miscellaneous costs willbe automatically updated from the scheduler, since they are calculated fromactual work. Re-plan stage schedule-Review the tracking Gantt and Cost workbookand identify any deviation from the baseline. Establish why the deviation hasoccurred. Refer back to the project control factors to help determine theappropriate corrective action and adjust the schedule accordingly. Determine


10/27

if the stage has exceeded the progress, cost and quality tolerance levelsagreed with the project management team. Review status of open issues anddetermine any further action required on these issues. Review the status ofany 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 activitiesthat are incomplete or overdue, activities for the next period, new issuesidentified this period, issues closed this period, summary of results of qualityreviews , summary of schedule and cost status, suggested revisions to theplan. Create status report The status report provides a record of currentachievement and immediate expectations of the project. The status has to beeffectively 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 providesa 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 andcorrective action.

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

Approvals Project stage reviews and the decisions taken and actions plannedneed to be approved by the top management. The goals of such review are toimprove quality by finding defects and to improve productivity by finding defectsin a cost effective manner. The group review process includes several stages likeplanning, preparation and overview a group review meeting and reworkrecommendations and follow-up.Change ControlControlling the changes in the project is possible through a proper changemanagement process and using necessary tools for controlling the change.Change control is necessary to control the increase of work at various stages ofproject and to manage effectively the disruptions in the stages, if any. Thesefactors may affect the progress of the project, resulting in deviations from thestage schedules, project and stage cost and project scope.

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


11/27

i. Request for a change- Identify need for a change based on which a formalrequest from either a member of the project team or a client or a coordinator orKey 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 thefunctional 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 planadjustments to accommodate the change, communicate these to teammembers, monitor progress and execute quality control on the changes.

Tools for Changing a processThere 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 requirescollection of all formal documented procedures, defining how projectperformance will be monitored and evaluated, how project plans could beupdated, how various measures can be implemented to control the changeprocess. These procedures may be unique to an organization based on theirproject needs. It also includes procedures to handle the changes that may beapproved without prior review, so that the evolution of baseline can bedocumented.b) Configuration Management (CM) Identify the configuration items anddefine the naming and numbering scheme, structure the changes, define abackup procedure, and follow the methods for tracking the status of configurationitems. 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 ClosureAny project that is planned properly and executed as per the plan will also closesuccessfully. For successful completion of a project every aspect of the projectshould be monitored and controlled.

Completion of all activities and benefitsThe closure of a project may result in the following benefits


12/27

1. It implies that on successful completion of a project, it has not drifted fromits intended course and plans. Otherwise it would have resulted in achange 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 upontheir 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 setupdata transfer, staff training etc.

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

a) Final product review The product obtained after every stage must meet therequirements of that stage. If it completely meets the stated objectives then focuson the issues of maintenance of the processes and product performance. If thefinal product does not completely meet the objectives then identify the variationsin the product and analyze the variation. Study the factors responsible for thechange and evaluate each one separately.

b) Outstanding project work review many a times it is found that there may besome item of the project which is still not in its stage finished form. It may beinsignificant as it may be a byproduct of that stage not required immediately forthe next stage. Then the items that are open should be resolved and necessarysteps 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, slipsand gains of time, adherence to the project definition and plans have to bereviewed. All such review details and reports have to be well documented forfuture use.


13/27

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

Q4. Explain the term knowledge factor.

Ans4.

1.1 Introduction

data base with technical or personal data in order to produce some usefulinformationfor a certain task. However, analyzing the requirements of problems CEOs havewhen they like to apply knowledge management as a technology leads to the fact

that the terms data, information and knowledge are used synonymously, thatthere isusually more than one source from which the useful information is extracted,andthat there is no architectural structure which may be used to describe neither therequirements nor the realization of the problem.A generic architecture will be presented which is based on the semiotic paradigmofinformation theory. The formal framework allows an adaptation of the architecturetospecial realizations and as such it covers standard information systems and database application systems. The architecture will be the kernel the metaphoricaldescription of a knowledge factory an may be enhanced with a collection ofhelpfulsoftware agents.Knowledge management is not a product in itself, nor asolution that organizations can buy off-the-shelf orassemble from various components. It is a processimplemented over a period of time, which has as much todo with human relationships as it does with business

practice and information technology(Benjamins, Fensel,Perez 1998)DATA, INFORMATION, AND KNOWLEDGEOne major problem with knowledge management is the fact that despite of theintensive academic discourse on the terms data, information, and knowledge, inindustrial practice they are used in an uncoordinated way. In the classical2interpretation data is associated with syntax, information corresponds tosemantic


14/27

and knowledge takes the pragmatic part. I.e. data per se has no meaning andmaybe seen as raw material for information. Information is context sensitive andmeaningful 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 beingtheresult of gathering information.(pragmatic)KNOWLEDGEDATA(syntactic)INFORMATION

(semantic)Figure 1a: The semiotic triangleDATAINFORMATIONKNOWLEDGEContext interpretedAction interpretedFigure 1b: Knowledge evolutionTurning the direction of reasoning leads to recent action oriented interpretations.According to (Nonaka 1994) knowledge is justified belief (i.e. information) thatincreases an entitys 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 ofknowledge 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 mayconsist of many data items and knowledge may consist of information plus actionrules. An example may be digital pictures: While on the data level only bit streams arerepresented the information level may contain additional format descriptions(especially those which identify the data as being a picture). Several and differentinformation may be derived from the same data. On the knowledge level there3may 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. Theinformation system may select pictures from the data base and only on theknowledge level a landscape painting could be distinguished from a portrait.

A GENERIC KNOWLEDGE MANAGEMENT ARCHITECTURE


15/27

Enterprises are recognizing that the enterprise knowledge management ratherthaninformation gathering and data collection is becoming one of their main businessfactors. Total Quality Management and Business Process Reengineering support

thecompanies to produce better products and to become more effective. However,theseactivities are usually not based on the enterprises experience and especiallythey donot support the talents of their best performers. Closest to knowledgemanagement is4the use of customized OLAP (Online Analytical Processing) tools to supportplanningactivities. However, OLAP systems operate on large data bases tying to solve

multidimensionalrequests for marketing, finance, and quality requests. Concerning thediscussion in the last section, this means that information is generated out ofdata.The resulting information gives rise to (knowledge based) decisions made byhumanplanners. In some cases expert systems are placed on top of OLAP tools in ordertorealize management support systems. If the expert system took care of using thecompanies expertise and practices, then it is a vertical knowledge managementsystem in the sense of (Bejamins, Fensel, and Perez 1998). In the following we

areinterested in defining a horizontal knowledge management system which incontrastis 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 systemsandknowledge processes support the flexible, though system-consistent modeling of knowledgemanagement systemsDataInformationGeneratorInformationKnowledgeGenerator


16/27

KnowledgeKnowledgeManagement Figure 2:Knowledge Management Architecture Visualization5

To visualize the knowledge management architecture the picture of an onionmightbe taken. It consist of circles which contains either container of material or toolstoproduce more complex material. To be more precise, the container are data-,information-, and knowledge bases. The tools are systems which use forinstancedata to produce information, like OLAP systems as discussed above. Cutting apiecefrom the center to the outside would then represent a specific knowledgemanagement system, while the whole structure would represent the knowledge

management facilities of an entire enterprise.

THE KNOWLEDGE FACTORYThe architecture introduced in the previous section uses objects and methods orfromthe view of abstract data types data and operations in the traditional sense. Sincetheknowledge management architecture should be used in different contexts and byvarious people, it would be worthwhile to extend the presentation byincorporating theagents who will use the tools. Hence, there is a change from the rigid

architecturaldescription to a more vivid picture which we call the knowledge factory. Itextendsthe traditional view of having material and tools to work on in a natural way. Likein afactory beside the production there are the people who produce. In our scenariothese are the knowledge workers and they will be incorporated into theframeworkby adding one more dimension. The following figure shows the new structure oftheknowledge factory.


17/27

Figure 3: The Knowledge Factory StructureThe first column shows the hierarchical structure of the different types of basicobjects: 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 thebasicobjects. Connecting the two columns with the arrows mirrors the simple parts oftheoperator definitions, namely Local(forth and back on the same level) and Lift(diagonal up). The Combi operators are implicitly presented with the thirdcolumn. Itrepresents the worker who use the tools of the second column. So theinformationworker applies tools of the data level and tools of the information level in order toproduce 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 ahierarchy respecting model, i.e. it is not allowed to skip a level neither verticallynorhorizontally. It may be a matter of discussion whether this strict proceeding isnecessary. However, theoretically all missing cases can be constructed bycombiningthe possible activities and on the practical side it is more secure if not everyonecando everything.


18/27


19/27

project manager should lead the team and control the project lifecycle as neithera second superior nor asubordinate of the core team members.

Size

Teams need to have expertise related to the anticipated issues and tasks, andthe more ideas the better.So larger teams, right? No, overwhelmingly team dynamic studies have shownlarger teams produce lessideas, less productivity, decreased team member buy-in, less participation, adecrease in cost effectiveness,and less accountability. There are many reasons for these outcomes. Too muchstakeholder involvement andlarge 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 ofeach member, and frequently creating biased decisions.

PlanningFrequently in an effort to appease the timeline and cost expectations of businesssponsors, projectteams move into the design phase with inadequate requirements or even intodevelopment with deficientdesign specifications. The amount of rework needed, which adds to cost andtimeline, will almost if notalways out-weight the time and money saved on planning. The correct response

to a decreased timeline is toincrease the efficiency of the planning phase; the most important phase of theproject. This may include abusiness analyst and IT Lead role to efficiently document requirements anddesign. But always requires theroles 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 anidea of where youare going before you can decide how you are going to get there, how long it willtake, and how much it willcost; time, scope, and budget balanced justly. Estimation tools based on high-level scope and historicalperformance can be developed to not only get ballpark figures in the infield, butgive a better start towardmaintaining cost and timeline during the execution phase. Estimation tools tunedby each department provideaccountability to project teams and functional departments, as well as increaseproject efficiency.


20/27

Project Kick-offThe invite list to project kick-off meetings should be based on both the perceivedimportance and truepriority of the project. Projects of high importance would have large kick-offs thatenable the high-level

scope and timeline to be communicated throughout the organization. This notonly establishes the core teamas described earlier, but brings up possible issues outside the core team, allowscross-functionalcommunication of key project issues and tasks, builds teamwork acrossdivisions, and increases employeebuy-in to the corporate strategies being met by the project.

Organizational CharacteristicsProject Management OfficeA Project Management Office (PMO) is a department responsible for

establishing, maintaining andenforcing project management standards throughout an organization. The PMOmust have the authority to setstandards via the support of executive management. Development of a trueorganizational PMO, regardless ofthe reporting department, is imperative to the implementation of effective cross-functional teams as well asthe successful prioritization of projects to the overall corporate strategies. PMOProject Managers must becapable of providing expertise, vision, and leadership to project teams.

EnablementThe number one dynamic that fosters success is enabling cross-functional teamsthe ability to succeedor fail. Micromanagement leads to less buy-in, less creativity, and groupthink;leading many individuals tofocus on making sure the project is simply not a failure and where to place blameif it does fail. Instead,management should support cross-functional project teams with the ability to fail;to have the ability to takerisks, to be creative, and to develop team based solutions that increase buy-in,productivity, and success.Management that continually second guesses team decisions demonstrates alack of trust and will decreasemotivation. This enablement is not a license to proceed with recklessabandonment either. In fact, it willincrease accountability.AccountabilityThe first step of project accountability is to have agreed upon projectmanagement processes. For


21/27

example, a document controls process that includes review and sign-off by keypersonnel at stage gates of aproject. These mutually agreed to processes are under constant improvementand tuning from the feedbackand review of project outcomes, resulting in further accountability. The next step

is the shared accountabilityof project outcomes to those within the cross-functional teams and all functionalareas involved; including thePMO and business areas. Often functional areas will (intentionally or not) limitproject involvement or allowbusiness decisions to be made by I.T. and then hold them responsible for anyfailures. It is human nature topush off accountability, and it takes effort to control the natural impulse of focuson oneself. Teamworkimprovements, group rewards, enablement, and cultural shifts; do what it takes toimprove accountability and

at the same time maintain or increase buy in to teamwork.

Proactive VisionToo often organizations react to unfavorable situations. They experience a realloss before makingany sincere change. Then, because of the loss, there is a demand for a timelyand sometimes very rushed andunder thought answer to the issue. The fact of the matter is, many risks can beavoided and efficiencies can berealized when organizations proactively adapt to coming change. This requiresproactive leadership with a

vision of turning risks into opportunities, who are willing and able to takeeducated risks. Individuals, whocontend for the success of the corporation and the survival of all, should beencouraged and rewarded.

Information TechnologyIt is surprising that in this technological age, some organizations still viewinformation technology aslittle more than a necessary evil. Information Technology is not just a servicedepartment, a supporter ofthose who do the real work, but a viable part of the development and executionof the business strategy. TheI.T. vs. The Business mentality does not stem from an inefficient IT Department,but inefficient crossfunctionalteams and a lack of accountability on both sides of the table. Informationtechnology takes thebrunt of the blame and the solution is not for senior management tomicromanage I.T., but to become more


22/27

actively involved in the development of the cross-functional teams that executebusiness strategy.

Organizational StructureCommunication of the corporate strategy is frequently too vague and hard to

quantify at both thefunctional and project level. Projects exist for corporate strategy to be realized;simple concept but frequentlyoverly complicated. It is the job of management to ensure that corporate goalsare communicated to the entireorganization. Companies must turn strategic priorities into assigned, measurableaction plans for not onlyproject 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 areward system related to projectwork. 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 meetingcorporate objectives isproactive responses to threats and opportunities. Most organizations support theproject management process,

however a strong focus on project team efficiency is still a significant culturalshift, and most are reactivelyaddressing the coming changes. With global commerce, approaching workforceshifts, industrytransformations, and economic downturn, organizations must proactively create andalign efficient crossfunctionalproject teams with corporate strategy to stay competitive.

Example:

Cross-functional teams are not new. Northwestern Mutual Life insurancecompany pioneered their use in the 1950s when the CEO of the companybrought together people from the financial, investment, actuarial, and otherdepartments to study the impact that computers would have on the businessworld. As a result of that firstCFT, Northwestern was among the first companiesin the country to create an information systems department that gave thecompany a large competitive advantage as computers gained in popularity. Thecompany now relies on cross-functional teams in almost every facet of itsorganization. Based on success stories like this one, CFTs slowly grew in
http://www.answers.com/topic/cfthttp://www.answers.com/topic/cfthttp://www.answers.com/topic/facethttp://www.answers.com/topic/cfthttp://www.answers.com/topic/facet


23/27

popularity throughout the 1960s and 1970s before exploding in popularity in the1980s when faster production time and increased organizational performancebecame critical in almost every industry.Cross-functional teams are similar to conventional work teams, but they differ inseveral 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 strongties to his or her home department that may conflict with the role he or she isbeing asked to play on the CFT). Second, in companies where CFTs are beingused on a part-time basis as opposed to a permanent organizational structure,they are often temporary groups organized for one important purpose, whichmeans group members are often under considerable pressure. On thesetemporary teams, the early development of stable and effective group interactionisimperative. Finally, CFTs are often held to higher performance standards thanconventional teams. Not only are they expected to perform a task or produce aproduct, 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 thatare 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 anuphill 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 videocoding standard and the assessment ofits performance at the completion of the work using formal subjective testingprocedures.The intent is that the ITU-T Recommendation and ISO/IEC InternationalStandard be technically aligned,fully interoperable with each other for all of the video codecs conformance pointsspecified during the termof this joint work, and offer the best possible technical performance under thepractical constraints of beingimplementable on various platforms and for various applications enabled by therelevant ITU-T
http://www.answers.com/topic/protomerhttp://www.answers.com/topic/imperativehttp://www.answers.com/topic/imperativehttp://www.answers.com/topic/disseminatehttp://www.answers.com/topic/uphillhttp://www.answers.com/topic/protomerhttp://www.answers.com/topic/imperativehttp://www.answers.com/topic/disseminatehttp://www.answers.com/topic/uphill


24/27

Recommendations and ISO/IEC International Standards. Common text will notbe used in the interest ofminimising co-ordination overhead.

2.0 Joint Group

The work of the project will be conducted by a jointly-constituted experts groupwhich will be known as theJoint Video Team (JVT).JVT will operate as a joint group under the ordinary policies and procedures ofboth organisations. In theevent of differences between policies of ISO/IEC and ITU-T not covered by theseToR, the JVTRapporteur|Chair will decide the issue, based on the consensus of the expertsand if necessary in consultationwith the parent bodies, in the best interests of standardization.3.0 Deliverables of the Joint Project

The deliverables are a new video codec informally called the JVT codec, to beapproved by ITU as an ITU-TRecommendation and by ISO/IEC as an International Standard. Thesedeliverables will be developed withrequirements as described.4.0 DissolutionThe joint group will dissolve when the approval process for the newRecommendation and InternationalStandard in both organisations is completed. The joint group may also bedissolved at the initiative of one orboth the parent bodies if unexpected conditions materialise that require one or

both of the parent bodies totake 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 suchagreement would be reached incase the need for a corrigendum is discovered.5.0 MeetingsJVT meeting venue and dates will be proposed by the JVT Rapporteur|Chair,and authorized by the parentbodies under the customary practices of both organisations.JVT meetings will be held as an entity that is separate from the two parentbodies, and will operate underrules set forth in Annex 3 of this ToR.The meeting dates and locations should be co-ordinated with those of meetingsof the ITU-T SG16 andISO/IEC JTC 1/SC 29/WG 11 (e.g. on an alternating basis if feasible for theprogress of the project) in order


25/27

to reduce the amount of travelling for participants and will be preferably co-located with a parent bodymeeting and held immediately before, during, or after the corresponding SG16meetings or during thecorresponding WG 11 meeting dates.

6.0 ManagementThe management of the JVT will consist of a jointly-appointed Rapporteur|Chairand two AssociateRapporteurs|Co-Chairs (one each as appointed from the parent bodies with jointconsent), reporting to theparent bodies. Changes in the management team must be agreed by the twoparent bodies.

8.0 Documents and ContributionsJVT will maintain a document registry and electronic distribution archive. Theregistry 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 theparticipants before the meetingthrough the use of electronic document handling. A registration and uploadingdeadline several days inadvance of the start of the meeting will be announced for each meeting. A late,unannounced documenthand-carried to the meeting should be accepted only with the consensus of themeeting participants. Thispolicy will be stated in the invitation letter that is provided for every meeting toboth organisations.

All documents and contributions will be in electronic form (preferably MS Word).In order to facilitate cross-organisational communication, all input and outputdocuments will be publicunless the contributor of an input document indicates otherwise. In thatcircumstance, the document will beaccessible only through a private, password-protected site accessible only toITU/ISO/IEC members andinvited experts regularly attending the JVT meetings. Invited experts not regularlyattending JVT meetingsmay be given access to such documents upon approval of its author.9.0 Working Methods9.1 General Policies and ProceduresAll group decisions will be made by the consensus of the JVT experts asdetermined by the JVTChair|Rapporteur. All contributions related to the joint project must be addressedto JVT for the duration ofthe joint project, rather than to the individual parent bodies. Additionally, thesemay also be submitted to any


26/27

of the parent bodies (according to their specific document submissionprocedures), if the author of thecontribution so determines.The general rules for handling new proposals, and general polices are describedin Annex 3.

9.2 Working relationship between JVT and the parent bodiesThe parent bodies may like to provide inputs (either in the form of writtendocuments or by holding meetingswith the appropriate parent body sub-groups) on the work carried out by JVT. Anon-exhaustive list includes:1. Further details on the high-level requirements already given in Annex 1.2. New requirements dictated by new applications that may be served by the newvideo coding3. Complexity analysis of the solutions being adopted4. Partitioning of the video coding tool space in profiles5. Definition of levels

6. Requirements for the design of verification tests7. Profiles to be tested in the verification tests.JVT will consider the inclusion of these inputs in its work, also considering theimpact of such inputs in theother parent bodys requirements. JVT will report back to the originatingorganisation on the action taken.9.3 Document ControlJVT will maintain a single master draft document and a single reference softwarecodebase for thedeveloping video coding standard, each under the control of a single editor,appointed by the JVT

4Chair|Rapporteur with the consensus of the experts. The document andcodebase will contain the exact textto be submitted to the parent bodies for approval. For maintenance of the text,see Section 4 (Dissolution).

12.0 Meeting ReportsA meeting report will be provided by the JVT management shortly after theconclusion of each meeting andwill be submitted to ITU TSB and ISO/IEC JTC 1/SC 29/WG 11, posted on thegroups FTP sites, anddistributed 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


27/27