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 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) InitiationIn 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) PlanningThe 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 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 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) ClosureIn 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

  * * ***

brainstormingBrainstorming 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.

Q4. Explain the term ‘knowledge factor’.

Ans4.

1.1 Introduction

data base with technical or personal data in order to produce some useful informationfor a certain task. However, analyzing the requirements of problems CEOs havewhen they like to apply knowledge management as a technology leads to the factthat the terms data, information and knowledge are used synonymously, that there 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 paradigm ofinformation theory. The formal framework allows an adaptation of the architecture tospecial 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 of helpfulsoftware 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 businesspractice 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 to semanticand knowledge takes the pragmatic part. I.e. data per se has no meaning and maybe 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 being theresult 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 entity’s capacity for effective action, while information is the flow ofmessages 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

Enterprises are recognizing that the enterprise knowledge management rather thaninformation 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 enterprise’s experience and especially they donot support the talents of their best performers. Closest to knowledge management is4the use of customized OLAP (Online Analytical Processing) tools to support planningactivities. 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 of data.The resulting information gives rise to (knowledge based) decisions made by humanplanners. In some cases expert systems are placed on top of OLAP tools in order torealize 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 are

interested in defining a horizontal knowledge management system which in contrastis 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 andknowledge processes· support the flexible, though system-consistent modeling of knowledgemanagement systemsDataInformationGeneratorInformationKnowledgeGeneratorKnowledgeKnowledgeManagement Figure 2:Knowledge Management Architecture Visualization5To visualize the knowledge management architecture the picture of an onion mightbe taken. It consist of circles which contains either container of material or tools toproduce more complex material. To be more precise, the container are data-,information-, and knowledge bases. The tools are systems which use for instancedata to produce information, like OLAP systems as discussed above. Cutting a piecefrom the center to the outside would then represent a specific knowledgemanagement system, while the whole structure would represent the knowledgemanagement facilities of an entire enterprise.

THE KNOWLEDGE FACTORYThe architecture introduced in the previous section uses objects and methods or fromthe view of abstract data types data and operations in the traditional sense. Since theknowledge management architecture should be used in different contexts and byvarious 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 architecturaldescription to a more vivid picture which we call the “knowledge factory”. It extendsthe traditional view of having material and tools to work on in a natural way. Like in afactory beside the production there are the people who produce. In our scenariothese are the “knowledge workers” and they will be incorporated into the frameworkby adding one more dimension. The following figure shows the new structure of theknowledge factory.

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 databases. With each level are associated the operator or tools used to work on the basicobjects. Connecting the two columns with the arrows mirrors the simple parts of theoperator definitions, namely Local (forth and back on the same level) and Lift(diagonal up). The Combi operators are implicitly presented with the third column. Itrepresents the worker who use the tools of the second column. So the informationworker 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 secondcolumn 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 vertically norhorizontally. It may be a matter of discussion whether this strict proceeding isnecessary. However, theoretically all missing cases can be constructed by combiningthe possible activities and on the practical side it is more secure if not everyone cando 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 CharacteristicsLeadershipAlthough 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 projectmanager’s influence on team members is less than the functional, are frequently mislabeled as crossfunctionalteams. However, they are not truly so because of the reporting structure. This situation causespriority 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 coremembers, 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 ofthe project team is an expert in their subject matter, the project manager is the subject matter expert in regardsto project management methodology, and most likely one of the members who best understands the projectsinterdependencies. To be a true cross-functional team, to be efficient and meet business requirements, theproject 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 lessideas, 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 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 business sponsors, projectteams move into the design phase with inadequate requirements or even into development with deficientdesign specifications. The amount of rework needed, which adds to cost and timeline, 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 the project. This may include abusiness analyst and IT Lead role to efficiently document requirements and design. 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 an idea of where youare going before you can decide how you are going to get there, how long it will take, 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, but give a better start towardmaintaining cost and timeline during the execution phase. Estimation tools tuned by each department provideaccountability to project teams and functional departments, as well as increase project efficiency.Project Kick-off

The invite list to project kick-off meetings should be based on both the perceived importance and truepriority of the project. Projects of high importance would have large kick-offs that enable the high-levelscope and timeline to be communicated throughout the organization. This not only establishes the core teamas described earlier, but brings up possible issues outside the core team, allows cross-functionalcommunication of key project issues and tasks, builds teamwork across divisions, 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 PMO must have the authority to setstandards via the support of executive management. Development of a true organizational 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. PMO Project Managers must becapable of providing expertise, vision, and leadership to project teams.

EnablementThe number one dynamic that fosters success is enabling cross-functional teams the 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 blame if 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 a lack of trust and will decreasemotivation. This enablement is not a license to proceed with reckless abandonment either. In fact, it willincrease 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 aproject. These mutually agreed to processes are under constant improvement and 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 functional areas involved; including thePMO and business areas. Often functional areas will (intentionally or not) limit project involvement or allowbusiness decisions to be made by I.T. and then hold them responsible for any failures. It is human nature topush off accountability, and it takes effort to control the natural impulse of focus on oneself. Teamworkimprovements, group rewards, enablement, and cultural shifts; do what it takes to improve accountability andat the same time maintain or increase buy in to teamwork.

Proactive VisionToo often organizations react to unfavorable situations. They experience a real loss before makingany sincere change. Then, because of the loss, there is a demand for a timely and sometimes very rushed andunder thought answer to the issue. The fact of the matter is, many risks can be avoided and efficiencies can berealized when organizations proactively adapt to coming change. This requires proactive leadership with avision of turning risks into opportunities, who are willing and able to take educated risks. Individuals, whocontend 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 aslittle more than a necessary evil. Information Technology is not just a service department, a supporter ofthose who do the real work, but a viable part of the development and execution of 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. Information technology takes thebrunt 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 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 goals are communicated to the entireorganization. Companies must turn strategic priorities into assigned, measurable action 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 a reward 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 meeting corporate objectives isproactive 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 reactivelyaddressing the coming changes. With global commerce, approaching workforce shifts, industrytransformations, and economic downturn, organizations must proactively create and align efficient crossfunctionalproject 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 ofits 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 termof this joint work, and offer the best possible technical performance under the practical constraints of beingimplementable on various platforms and for various applications enabled by the relevant ITU-TRecommendations and ISO/IEC International Standards. Common text will not be used in the interest ofminimising co-ordination overhead.

2.0 Joint GroupThe work of the project will be conducted by a jointly-constituted experts group which will be known as theJoint Video Team (“JVT”).JVT will operate as a joint group under the ordinary policies and procedures of both organisations. In theevent of differences between policies of ISO/IEC and ITU-T not covered by these ToR, the JVTRapporteur|Chair will decide the issue, based on the consensus of the experts and if necessary in consultationwith the parent bodies, in the best interests of standardization.3.0 Deliverables of the Joint ProjectThe deliverables are a new video codec informally called the JVT codec, to be approved by ITU as an ITU-TRecommendation and by ISO/IEC as an International Standard. These deliverables will be developed withrequirements as described.4.0 DissolutionThe joint group will dissolve when the approval process for the new Recommendation and InternationalStandard in both organisations is completed. The joint group may also be dissolved 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 such agreement 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 parent bodies, and will operate underrules 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 andISO/IEC JTC 1/SC 29/WG 11 (e.g. on an alternating basis if feasible for the progress of the project) in orderto 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 SG16 meetings or during thecorresponding WG 11 meeting dates.

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

8.0 Documents and ContributionsJVT will maintain a document registry and electronic distribution archive. The registry and archive will belinked 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 meetingthrough the use of electronic document handling. A registration and uploading deadline 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 the meeting participants. Thispolicy 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 publicunless the contributor of an input document indicates otherwise. In that circumstance, the document will beaccessible only through a private, password-protected site accessible only to ITU/ISO/IEC members andinvited experts regularly attending the JVT meetings. Invited experts not regularly attending 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 as determined by the JVTChair|Rapporteur. All contributions related to the joint project must be addressed to JVT for the duration ofthe 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 thecontribution so determines.The general rules for handling new proposals, and general polices are described in Annex 3.9.2 Working relationship between JVT and the parent bodies

The parent bodies may like to provide inputs (either in the form of written documents or by holding meetingswith the appropriate parent body sub-groups) on the work carried out by JVT. A non-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 new video coding3. Complexity analysis of the solutions being adopted4. Partitioning of the video coding tool space in profiles5. Definition of levels6. 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 the impact of such inputs in theother parent body’s requirements. JVT will report back to the originating organisation on the action taken.9.3 Document ControlJVT will maintain a single master draft document and a single reference software codebase for thedeveloping video coding standard, each under the control of a single editor, appointed by the JVT4Chair|Rapporteur with the consensus of the experts. The document and codebase 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 the conclusion of each meeting andwill be submitted to ITU TSB and ISO/IEC JTC 1/SC 29/WG 11, posted on the group’s 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• Any outgoing liaison statements/communications sent to other organisations• Future activities13.0 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 promotionand public relations activities will undergo review and consent by both parent bodies (VCEG and MPEG, ifnecessary in consultation with higher-level committee management).