Beruflich Dokumente
Kultur Dokumente
(Book ID :)
Assignment Set- 1 (60 Marks)
Ans1.
Diverse project management tools and methodologies prevail in the different project cycle
phases. Let’s take a closer look at what’s important in each one of these stages:
1) Initiation
In this first stage, the scope of the project is defined along with the approach to be taken to
deliver the desired outputs. The project manager is appointed and in turn, he selects the team
members based on their skills and experience. The most common tools or methodologies used
in the initiation stage are Project Charter, Business Plan, Project Framework (or Overview),
Business Case Justification, and Milestones Reviews.
2) Planning
The second phase should include a detailed identification and assignment of each task until the
end of the project. It should also include a risk analysis and a definition of a criteria for the
successful completion of each deliverable. The governance process is defined, stake holders
identified and reporting frequency and channels agreed. The most common tools or
methodologies used in the planning stage are Business Plan and Milestones Reviews.
4) Closure
In this last stage, the project manager must ensure that the project is brought to its proper
completion. The closure phase is characterized by a written formal project review report
containing the following components: a formal acceptance of the final product by the client,
Weighted Critical Measurements (matching the initial requirements specified by the client with
the final delivered product), rewarding the team, a list of lessons learned, releasing project
resources, and a formal project closure notification to higher management. No special tool or
methodology is needed during the closure phase.
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 = Brainstorming
F = Fishbone/Ishikawa Diagrams *** -main tool
C = Critical Path Analysis Flow Diagrams ** - optional/secondary
tool
G = Gantt Charts * -sometimes useful
B F C G
Project brainstorming and initial concepts, ideas, structures,
*** **
aims, etc
Gathering and identifying all elements, especially causal
* *** **
and hidden factors
Scheduling and timescales ** ***
Identifying and sequencing parallel and interdependent
* *** *
activities and stages
Financials - costings, budgets, revenues, profits, variances,
* * ** ***
etc
Monitoring, forecasting, reporting * ** ***
Troubleshooting, problem identification, diagnosis and
** *** ** *
solutions
'Snapshot' or 'map' overview - non-sequential, non-
** ***
scheduled
Format for communications, presentations, updates,
* * ***
progress reports, etc
brainstorming
Brainstorming is usually the first crucial creative stage of the project management and
project planning process. See the brainstorming method in detail and explained
separately, because it many other useful applications outside of project management.
Unlike most project management skills and methods, the first stages of the brainstorming
process is ideally a free-thinking and random technique. Consequently it can be
overlooked or under-utilized because it not a natural approach for many people whose
mains strengths are in systems and processes. Consequently this stage of the project
planning process can benefit from being facilitated by a team member able to manage
such a session, specifically to help very organised people to think randomly and
creatively.
fishbone diagrams
Fishbone 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 charts
Gantt Charts (commonly wrongly called gant charts) are extremely useful project
management tools. The Gantt Chart is named after US engineer and consultant Henry
Gantt (1861-1919) who devised the technique in the 1910s.
Gantt charts are excellent models for scheduling and for budgeting, and for reporting and
presenting and communicating project plans and progress easily and quickly, but as a rule
Gantt Charts are not as good as a Critical Path Analysis Flow Diagram for identifying
and showing interdependent factors, or for 'mapping' a plan from and/or into all of its
detailed causal or contributing elements.
You can construct a Gantt Chart using MSExcel or a similar spreadsheet. Every activity
has a separate line. Create a time-line for the duration of the project (the breakfast
example shows minutes, but normally you would use weeks, or for very big long-term
projects, months). You can colour code the time blocks to denote type of activity (for
example, intense, watching brief, directly managed, delegated and left-to-run, etc.) You
can schedule review and insert break points. At the end of each line you can show as
many cost columns for the activities as you need. The breakfast example shows just the
capital cost of the consumable items and a revenue cost for labour and fuel. A Gantt chart
like this can be used to keep track of progress for each activity and how the costs are
running. You can move the time blocks around to report on actuals versus planned, and to
re-schedule, and to create new plan updates. Costs columns can show plan and actuals
and variances, and calculate whatever totals, averages, ratios, etc., that you need. Gantt
Charts are probably the most flexible and useful of all project management tools, but
remember they do not very easily or obviously show the importance and inter-
dependence of related parallel activities, and they won't obviously show the necessity to
complete one task before another can begin, as a Critical Path Analysis will do, so you
may need both tools, especially at the planning stage, and almost certainly for large
complex projects.
gantt chart example
A wide range of computerised systems/software now exists for project management and
planning, and new methods continue to be developed. It is an area of high innovation,
with lots of scope for improvement and development. I welcome suggestions of
particularly good systems, especially if inexpensive or free. Many organizations develop
or specify particular computerised tools, so it's a good idea to seek local relevant advice
and examples of best practice before deciding the best computerised project management
system(s) for your own situation.
Project planning tools naturally become used also for subsequent project reporting,
presentations, etc., and you will make life easier for everyone if you use formats that
people recognize and find familiar.
Q3. Describe the various steps involved in monitoring and controlling a project
Ans:- Project Monitoring and Control
Any project aimed at delivering a product or a service has to go through phases
in a planned manner in order to meet the requirements. It is possible to work
according to the project plan only by careful monitoring of the project
progress. It requires establishing control factors to keep the project on the
track of progress. The results of any stage in a project, depends on the inputs
to that stage. It is therefore necessary to control all the inputs and the
corresponding outputs from a stage. A project manager may use certain
standard tools to keep the project on track. The project manager and the team
members should be fully aware of the techniques and methods to rectify the
factors influencing delay of the project and its product. The various steps
involved in monitoring and controlling a project from start to end are as
follows –
Preliminary work – the team members understand the project plans, project
stage schedule, progress controls, tracking schedules, summary of the stage
cost and related worksheets. All the member has to understand the tolerances
in any change and maintain a change control log. They must realize the need
and importance of quality for which they have to follow strictly a quality
review schedule and frequently discuss on the quality agendas. They must
understand the stage status reports, stage end reports, stage end approval
reports.
Project Progress – The members must keep a track of the project progress and
communicate the same to other related members of the project. They must
monitor and control project progress, through the use of regular check points,
quality charts, and statistical tables, control the quality factors which are
likely to deviate from expected values as any deviation may result in changes
to the stage schedule. The project manager ensures that these changes are
made smoothly and organizes review meeting with the project management
group.
Stage Control – The manager must establish a project check point cycle. For
this suitable stage version control procedures may be followed. The details are
to be documented stage wise. Project files have to be frequently updated with
suitable version control number and revision status should be maintained for
each change. Team members are identified who will exercise controls at
various points of the project.
Resources – Plan the resources required for various stage of the project. Brief
both the project team and the key resources about the objectives of every
stage, planned activities, products, organization, metrics and project controls
• Update costs - Update the stage cost summary worksheet with actual
costs incurred this period, estimated remaining costs. Miscellaneous costs
will be automatically updated from the scheduler, since they are calculated
from actual work.
• Re-plan stage schedule-Review the tracking Gantt and Cost workbook
and identify any deviation from the baseline. Establish why the deviation
has occurred. Refer back to the project control factors to help determine
the appropriate corrective action and adjust the schedule accordingly.
Determine if the stage has exceeded the progress, cost and quality
tolerance levels agreed with the project management team. Review status
of open issues and determine any further action required on these issues.
Review the status of any outstanding quality reviews Review any new
change requests.
• Conduct team status review- Conduct a status meeting with the project
team. Items for discussion are achievements this period planned activities
that are incomplete or overdue, activities for the next period, new issues
identified this period, issues closed this period, summary of results of
quality reviews , summary of schedule and cost status, suggested revisions
to the plan.
• Create status report – The status report provides a record of current
achievement and immediate expectations of the project. The status has to
be effectively communicated to all interested parties.
• Create Flash report - summarize the accomplishments for the month,
schedule status, upcoming tasks for the month and any major issues.
Distribute to the project team and project management team
• Project Status Reports - As discussed earlier, the status report provides
a record of current achievements and immediate expectations of the
project.
A weekly status report includes:
- Any predicted slippage to the stage schedule, along with cause and
corrective action.
- Any predicted cost overrun along with cause and corrective action.
Approvals – Project stage reviews and the decisions taken and actions planned
need to be approved by the top management. The goals of such review are to
improve quality by finding defects and to improve productivity by finding
defects in a cost effective manner. The group review process includes several
stages like planning, preparation and overview a group review meeting and
rework recommendations and follow-up.
Change Control
Controlling the changes in the project is possible through a proper change
management process and using necessary tools for controlling the change.
Change control is necessary to control the increase of work at various stages of
project and to manage effectively the disruptions in the stages, if any. These
factors may affect the progress of the project, resulting in deviations from the
stage schedules, project and stage cost and project scope.
ii. Identify Alternate Solutions – Evaluate the change request and identify
several alternative solutions. Assess the alternatives with respect to the
functional scope, schedule, effort and cost.
iii. Decide on the Actions for the change – Present the change request,
alternative solutions and recommendation to the project management team.
The project management team is required to accept the recommendation,
choose an alternative solution, or request further investigation.
iv. Implement change – make appropriate schedule and other project plan
adjustments to accommodate the change, communicate these to team
members, monitor progress and execute quality control on the changes.
Project Closure
Any project that is planned properly and executed as per the plan will also
close successfully. For successful completion of a project every aspect of the
project should be monitored and controlled.
a) Final product review – The product obtained after every stage must meet the
requirements of that stage. If it completely meets the stated objectives then
focus on the issues of maintenance of the processes and product performance.
If the final product does not completely meet the objectives then identify the
variations in the product and analyze the variation. Study the factors
responsible for the change and evaluate each one separately.
b) Outstanding project work review – many a times it is found that there may
be some item of the project which is still not in its stage finished form. It may
be insignificant as it may be a byproduct of that stage not required
immediately for the next stage. Then the items that are open should be
resolved and necessary steps be taken to close such open items.
d) Process review – Every process is important in any project. One may review
the process to see if any changes can be made to improve its performance.
Ans4.
1.1 Introduction
data base with technical or personal data in order to produce some useful information
for a certain task. However, analyzing the requirements of problems CEOs have
when they like to apply knowledge management as a technology leads to the fact
that the terms data, information and knowledge are used synonymously, that there is
usually more than one source from which the “useful information” is extracted, and
that there is no architectural structure which may be used to describe neither the
requirements nor the realization of the problem.
A generic architecture will be presented which is based on the semiotic paradigm of
information theory. The formal framework allows an adaptation of the architecture to
special realizations and as such it covers standard information systems and data
base application systems. The architecture will be the kernel the metaphorical
description of a knowledge factory an may be enhanced with a collection of helpful
software agents.
“Knowledge management is not a product in itself, nor a
solution that organizations can buy off-the-shelf or
assemble from various components. It is a process
implemented over a period of time, which has as much to
do with human relationships as it does with business
practice and information technology” (Benjamins, Fensel,
Perez 1998)
DATA, INFORMATION, AND KNOWLEDGE
One major problem with knowledge management is the fact that despite of the
intensive academic discourse on the terms data, information, and knowledge, in
industrial practice they are used in an uncoordinated way. In the classical
2
interpretation data is associated with syntax, information corresponds to semantic
and knowledge takes the pragmatic part. I.e. data per se has no meaning and may
be seen as raw material for information. Information is context sensitive and
meaningful in the sense that it is interpreted data. Since context is user (application)
dependant information then may be enhanced by its use, i.e. the pragmatic.
knowledge.
The semiotic correspondence of data, information, and knowledge thus interprets
information as being the result of the transmitting knowledge and data as being the
result of gathering information.
(pragmatic)
KNOWLEDGE
DATA
(syntactic)
INFORMATION
(semantic)
Figure 1a: The semiotic triangle
DATA
INFORMATION
KNOWLEDGE
Context interpreted
Action interpreted
Figure 1b: Knowledge evolution
Turning the direction of reasoning leads to recent action oriented interpretations.
According to (Nonaka 1994) knowledge is justified belief (i.e. information) that
increases an entity’s capacity for effective action, while information is the flow of
messages or meaning which may add to, restructure, or change knowledge (Probst,
Raub, Romhardt 1998). In that sense information is raw material for production of
knowledge and information transforms to knowledge in the context of actions.
However, it would be wrong to imply a pure set inclusion between the three, i.e.
knowledge is a subset of information which is a subset of data. Information may
consist of many data items and knowledge may consist of information plus action
rules.
· An example may be digital pictures: While on the data level only bit streams are
represented the information level may contain additional format descriptions
(especially those which identify the data as being a picture). Several and different
information may be derived from the same data. On the knowledge level there
3
may be semantic descriptors identifying the type of the picture (e.g. a landscape).
Now searching for landscape pictures in the data base would have no result. The
information system may select pictures from the data base and only on the
knowledge level a landscape painting could be distinguished from a portrait.
Enterprises are recognizing that the enterprise knowledge management rather than
information gathering and data collection is becoming one of their main business
factors. Total Quality Management and Business Process Reengineering support the
companies to produce better products and to become more effective. However, these
activities are usually not based on the enterprise’s experience and especially they do
not support the talents of their best performers. Closest to knowledge management is
4
the use of customized OLAP (Online Analytical Processing) tools to support planning
activities. However, OLAP systems operate on large data bases tying to solve
multidimensional
requests for marketing, finance, and quality requests. Concerning the
discussion in the last section, this means that information is generated out of data.
The resulting information gives rise to (knowledge based) decisions made by human
planners. In some cases expert systems are placed on top of OLAP tools in order to
realize management support systems. If the expert system took care of using the
companies expertise and practices, then it is a vertical knowledge management
system in the sense of (Bejamins, Fensel, and Perez 1998). In the following we are
interested in defining a horizontal knowledge management system which in contrast
is not designed for a special business situation, but usable for different settings.
The Idea
The aim is to develop a generic architecture for knowledge management systems
and processes which should
· respect the differentiation of data, information, and knowledge
· be used as a scheme to classify various types of enterprise business systems and
knowledge processes
· support the flexible, though system-consistent modeling of knowledge
management systems
Data
Information
Generator
Information
Knowledge
Generator
Knowledge
Knowledge
Management Figure 2:
Knowledge Management Architecture Visualization
5
To visualize the knowledge management architecture the picture of an onion might
be taken. It consist of circles which contains either container of material or tools to
produce more complex material. To be more precise, the container are data-,
information-, and knowledge bases. The tools are systems which use for instance
data to produce information, like OLAP systems as discussed above. Cutting a piece
from the center to the outside would then represent a specific knowledge
management system, while the whole structure would represent the knowledge
management facilities of an entire enterprise.
Ans5. The most simple definition of cross-functional teams (or CFTs) is teams that are
made up of people from different functional areas within a company—marketing,
engineering, sales, and human resources, for example. These teams take many forms, but
they are most often set up as working groups that are designed to make decisions at a
lower level than is customary in a given company. They can be either a company's
primary form of organizational structure, or they can exist in addition to the company's
main hierarchical structure.
Cross-functional teams have become more popular in recent years for three primary
reasons: they improve coordination and integration, span organizational boundaries, and
reduce the production cycle time in new product development. Bringing people together
from different disciplines can improve problem solving and lead to more thorough
decision making. The teams foster a spirit of cooperation that can make it easier to
achieve customer satisfaction and corporate goals at the same time.
Team Characteristics
Leadership
Although fading in popularity, matrix structured organizations still exist. In a matrix
environment,
team members report directly to both their functional manager as well as one or more
project managers:
literally a multi-manager scenario. Teams in a weak matrix environment, especially
where the project
manager’s influence on team members is less than the functional, are frequently
mislabeled as crossfunctional
teams. However, they are not truly so because of the reporting structure. This situation
causes
priority conflicts and animosity that result in inefficiencies to both functional groups and
project teams.
Teams with project managers that are lower on the organizational chart than the rest of
the core
members, are also frequently mislabeled as a cross-functional team. Common results
include biased scope,
poor implementation of project management standards, and a lack of true leadership. Just
as each member of
the project team is an expert in their subject matter, the project manager is the subject
matter expert in regards
to project management methodology, and most likely one of the members who best
understands the projects
interdependencies. To be a true cross-functional team, to be efficient and meet business
requirements, the
project manager should lead the team and control the project lifecycle as neither a second
superior nor a
subordinate of the core team members.
Size
Teams need to have expertise related to the anticipated issues and tasks, and the more
ideas the better.
So larger teams, right? No, overwhelmingly team dynamic studies have shown larger
teams produce less
ideas, less productivity, decreased team member buy-in, less participation, a decrease in
cost effectiveness,
and less accountability. There are many reasons for these outcomes. Too much
stakeholder involvement and
large team size both create withdrawn members and a groupthink atmosphere. More
assertive members end
up making the majority of decisions; literally making the decision team smaller, reducing
the cost benefit of
each member, and frequently creating biased decisions.
Planning
Frequently in an effort to appease the timeline and cost expectations of business sponsors,
project
teams move into the design phase with inadequate requirements or even into development
with deficient
design specifications. The amount of rework needed, which adds to cost and timeline,
will almost if not
always out-weight the time and money saved on planning. The correct response to a
decreased timeline is to
increase the efficiency of the planning phase; the most important phase of the project.
This may include a
business analyst and IT Lead role to efficiently document requirements and design. But
always requires the
roles and responsibilities of the core project team to be clearly defined.
Estimating
A key piece of planning is the estimation of cost and timeline. It is vital to have an idea of
where you
are going before you can decide how you are going to get there, how long it will take, and
how much it will
cost; time, scope, and budget balanced justly. Estimation tools based on high-level scope
and historical
performance can be developed to not only get ballpark figures in the infield, but give a
better start toward
maintaining cost and timeline during the execution phase. Estimation tools tuned by each
department provide
accountability to project teams and functional departments, as well as increase project
efficiency.
Project Kick-off
The invite list to project kick-off meetings should be based on both the perceived
importance and true
priority of the project. Projects of high importance would have large kick-offs that enable
the high-level
scope and timeline to be communicated throughout the organization. This not only
establishes the core team
as described earlier, but brings up possible issues outside the core team, allows cross-
functional
communication of key project issues and tasks, builds teamwork across divisions, and
increases employee
buy-in to the corporate strategies being met by the project.
Organizational Characteristics
Project Management Office
A Project Management Office (PMO) is a department responsible for establishing,
maintaining and
enforcing project management standards throughout an organization. The PMO must
have the authority to set
standards via the support of executive management. Development of a true organizational
PMO, regardless of
the reporting department, is imperative to the implementation of effective cross-
functional teams as well as
the successful prioritization of projects to the overall corporate strategies. PMO Project
Managers must be
capable of providing expertise, vision, and leadership to project teams.
Enablement
The number one dynamic that fosters success is enabling cross-functional teams the
ability to succeed
or fail. Micromanagement leads to less buy-in, less creativity, and groupthink; leading
many individuals to
focus on making sure the project is simply not a failure and where to place blame if it
does fail. Instead,
management should support cross-functional project teams with the ability to fail; to have
the ability to take
risks, to be creative, and to develop team based solutions that increase buy-in,
productivity, and success.
Management that continually second guesses team decisions demonstrates a lack of trust
and will decrease
motivation. This enablement is not a license to proceed with reckless abandonment either.
In fact, it will
increase accountability.
Accountability
The first step of project accountability is to have agreed upon project management
processes. For
example, a document controls process that includes review and sign-off by key personnel
at stage gates of a
project. These mutually agreed to processes are under constant improvement and tuning
from the feedback
and review of project outcomes, resulting in further accountability. The next step is the
shared accountability
of project outcomes to those within the cross-functional teams and all functional areas
involved; including the
PMO and business areas. Often functional areas will (intentionally or not) limit project
involvement or allow
business decisions to be made by I.T. and then hold them responsible for any failures. It
is human nature to
push off accountability, and it takes effort to control the natural impulse of focus on
oneself. Teamwork
improvements, group rewards, enablement, and cultural shifts; do what it takes to
improve accountability and
at the same time maintain or increase buy in to teamwork.
Proactive Vision
Too often organizations react to unfavorable situations. They experience a real loss
before making
any sincere change. Then, because of the loss, there is a demand for a timely and
sometimes very rushed and
under thought answer to the issue. The fact of the matter is, many risks can be avoided
and efficiencies can be
realized when organizations proactively adapt to coming change. This requires proactive
leadership with a
vision of turning risks into opportunities, who are willing and able to take educated risks.
Individuals, who
contend for the success of the corporation and the survival of all, should be encouraged
and rewarded.
Information Technology
It is surprising that in this technological age, some organizations still view information
technology as
little more than a necessary evil. Information Technology is not just a service department,
a supporter of
those who do the real work, but a viable part of the development and execution of the
business strategy. The
I.T. vs. “The Business” mentality does not stem from an inefficient IT Department, but
inefficient crossfunctional
teams and a lack of accountability on both sides of the table. Information technology
takes the
brunt of the blame and the solution is not for senior management to micromanage I.T.,
but to become more
actively involved in the development of the cross-functional teams that execute business
strategy.
Organizational Structure
Communication of the corporate strategy is frequently too vague and hard to quantify at
both the
functional and project level. Projects exist for corporate strategy to be realized; simple
concept but frequently
overly complicated. It is the job of management to ensure that corporate goals are
communicated to the entire
organization. Companies must turn strategic priorities into assigned, measurable action
plans for not only
project teams, but for each functional department.
Rewarding
Organizations of course need to support the time and effort required for development of
team skills.
One frequently missed medium for accomplishing this objective is through a reward
system related to project
work. Rewards should be based on strategic results: both short-term and long-term
successes.
Conclusion
Change is the only constant, and the key variable to effectively meeting corporate
objectives is
proactive responses to threats and opportunities. Most organizations support the project
management process,
however a strong focus on project team efficiency is still a significant cultural shift, and
most are reactively
addressing the coming changes. With global commerce, approaching workforce
shifts, industry
transformations, and economic downturn, organizations must proactively create
and align efficient crossfunctional
project teams with corporate strategy to stay competitive.
Example:
Cross-functional teams are not new. Northwestern Mutual Life insurance company
pioneered their use in the 1950s when the CEO of the company brought together people
from the financial, investment, actuarial, and other departments to study the impact that
computers would have on the business world. As a result of that first CFT, Northwestern
was among the first companies in the country to create an information systems
department that gave the company a large competitive advantage as computers gained in
popularity. The company now relies on cross-functional teams in almost every facet of its
organization. Based on success stories like this one, CFTs slowly grew in popularity
throughout the 1960s and 1970s before exploding in popularity in the 1980s when faster
production time and increased organizational performance became critical in almost
every industry.
Cross-functional teams are similar to conventional work teams, but they differ in several
important ways. First, they are usually composed of members who have competing
loyalties and obligations to their primary subunit within the company (for example, a
marketing person serving on a cross-functional team has strong ties to his or her home
department that may conflict with the role he or she is being asked to play on the CFT).
Second, in companies where CFTs are being used on a part-time basis as opposed to a
permanent organizational structure, they are often temporary groups organized for one
important purpose, which means group members are often under considerable pressure.
On these temporary teams, the early development of stable and effective group
interaction is imperative. Finally, CFTs are often held to higher performance standards
than conventional teams. Not only are they expected to perform a task or produce a
product, but they are also expected to reduce cycle time, create knowledge about the CFT
process, and disseminate that knowledge throughout the organization.
For cross-functional teams to succeed, several factors have been identified that are
imperative:
• Team members must be open-minded and highly motivated.
• Team members must come from the correct functional areas.
• A strong team leader with excellent communication skills and a position of
authority is needed.
• The team must have both the authority and the accountability to accomplish the
mission it has been given.
• Management must provide adequate resources and support for the team, both
moral and financial.
• Adequate communications must exist.
Without any one of these elements, any cross-functional team will be fighting an uphill
battle to succeed.
Ans6. The scope of the joint project will be the development of a new video coding
standard and the assessment of
its performance at the completion of the work using formal subjective testing procedures.
The intent is that the ITU-T Recommendation and ISO/IEC International Standard be
technically aligned,
fully interoperable with each other for all of the video codec’s conformance points
specified during the term
of this joint work, and offer the best possible technical performance under the practical
constraints of being
implementable on various platforms and for various applications enabled by the relevant
ITU-T
Recommendations and ISO/IEC International Standards. Common text will not be used
in the interest of
minimising co-ordination overhead.
2.0 Joint Group
The work of the project will be conducted by a jointly-constituted experts group which
will be known as the
Joint Video Team (“JVT”).
JVT will operate as a joint group under the ordinary policies and procedures of both
organisations. In the
event of differences between policies of ISO/IEC and ITU-T not covered by these ToR,
the JVT
Rapporteur|Chair will decide the issue, based on the consensus of the experts and if
necessary in consultation
with the parent bodies, in the best interests of standardization.
3.0 Deliverables of the Joint Project
The deliverables are a new video codec informally called the JVT codec, to be approved
by ITU as an ITU-T
Recommendation and by ISO/IEC as an International Standard. These deliverables will
be developed with
requirements as described.
4.0 Dissolution
The joint group will dissolve when the approval process for the new Recommendation
and International
Standard in both organisations is completed. The joint group may also be dissolved at the
initiative of one or
both the parent bodies if unexpected conditions materialise that require one or both of the
parent bodies to
take this action.
Potential new joint work beyond the duration of this project (e.g., extensions, corrigenda,
amendments, etc.)
will require the agreement of the two parent bodies. It is anticipated that such agreement
would be reached in
case the need for a corrigendum is discovered.
5.0 Meetings
JVT meeting venue and dates will be proposed by the JVT Rapporteur|Chair, and
authorized by the parent
bodies under the customary practices of both organisations.
JVT meetings will be held as an entity that is separate from the two parent bodies, and
will operate under
rules set forth in Annex 3 of this ToR.
The meeting dates and locations should be co-ordinated with those of meetings of the
ITU-T SG16 and
ISO/IEC JTC 1/SC 29/WG 11 (e.g. on an alternating basis if feasible for the progress of
the project) in order
to reduce the amount of travelling for participants and will be preferably co-located with
a parent body
meeting and held immediately before, during, or after the corresponding SG16 meetings
or during the
corresponding WG 11 meeting dates.
6.0 Management
The management of the JVT will consist of a jointly-appointed Rapporteur|Chair and two
Associate
Rapporteurs|Co-Chairs (one each as appointed from the parent bodies with joint consent),
reporting to the
parent bodies. Changes in the management team must be agreed by the two parent bodies.
7. Reset objectives for next period – The targets are revised either
upward or downward depending on the conclusion of the appraisal
process.
(j) Coping with changes: It is often said – ‘The only constant in this world
is change’. A professional manager has the ability and capacity to cope
with change. He accepts the fact that change is inevitable and is ready
to implement change at the workplace. To implement change
successfully, it is essential that employees are involved in the
implementation of change. Further the positive and negative
consequences of change need to be discussed and understood before
implementation. Thus a professional manager has the attitude to accept
change as a way of life and takes it in his stride
Q2. Is substitution necessary?
Ans. Technology Substitution
Technology substitution is based on the fact that several alternate
technological routes are available to create a particular device. These
alternate routes are normally hidden behind the commonly known processes, in
different forms. Identification of these hidden technologies will open up
opportunities for technology substitution. Some of the examples of technology
substitution are in the fields of Aerospace, Automobile, water storage dams,
etc. We give just two examples from the aerospace industry. In recent years,
because of the versatility of software programmes which can be written to
simulate a variety of operating conditions, a great amount of work is going on –
both in terms of variety and depth.
In the same way, a wide variety of subsystems for commercial and industrial
uses have many components which are used by the manufacturing
organizations. It is well known that many of them find military applications and
are made especially for them. However, these are superior than those used for
industrial purposes for obvious reasons. With some minor improvements they
can be used for superior performance when such requirement can bear a little
higher cost.
Q3. In what ways can an ERP package be utilized? Explain
Ans:- The Role of Effective Data Management in the Success of Project
Management
Data management consists in conducting activities which facilitate in acquiring
data, processing it and distributing it. Acquisition of data is the primary
function. Data to be useful should have three important characteristics –
relevancy, sufficiency and timeliness. Management of acquisition lies in
ensuring that these are satisfied – before they are stored for processing and
decisions taken on the analyses. We will have data about customers, suppliers,
market conditions, new technology, opportunities, human resources, economic
activities, government regulations, political upheavals, – all of which affect the
way we function. Most of the data go on changing because the aforesaid
sources have uncertainty inherent in them. So updating data is a very
important aspect of their management.
It contains details about all materials that go into the project at various stages
and has to be continuously updated as all members of the project depend upon
it for providing materials for their apportioned areas of execution. Since
information is shared by all members, there is an opportunity for utilizing some
of them when others do not need them. To ascertain availability at some
future point of time, information about orders placed, backlogs, lead times are
important for all the members. A proper MIS will take care of all these aspects.
ERP packages help in integrating data from all sources and present them to
individual members in the way they require. When all these are done
efficiently the project will have no hold ups an assure success.
Risk Analysis
The first step in risk analysis is to make each risk item more specific. Risks such
as, “Lack of Management buy-in,” and “people might leave,” are a little
ambiguous. In these cases the group might decide to split the risk into smaller
specific risks, such as, “manager Jane decides that the project is not
beneficial,” “Database expert might leave,” and “Webmaster might get pulled
off the project.”
The next step is to set priorities and determine where to focus risk mitigation
efforts. Some of the identified risks are unlikely to occur, and others might not
be serious enough to worry about. During the analysis, discuss with the team
members, each risk item to understand how devastating it would be if it did
occur, and how likely it is to occur. For example, if you had a risk of a key
person leaving, you might decide that it would have a large impact on the
project, but that it is not very likely.
In the process below, we have the group agree on how likely it thinks each risk
item is to occur, using a simple scale from 1 to 10 (where 1 is very unlikely and
10 is very likely). The group then rates how serious the impact would be if the
risk did occur, using a simple scale from 1 to 10 (where 1 is little impact and 10
is very large). To use this numbering scheme, first pick out the items that rate
1 and 10, respectively. Then rate the other items relative to these boundaries.
To determine the priority of each risk item, calculate the product of the two
values, likelihood and impact. This priority scheme helps push the big risks to
the top of the list, and the small risks to the bottom. It is a usual practice to
analyze risk either by sensitivity analysis or by probabilistic analysis.
Second, we can take action to reduce the impact if the risk does occur.
Sometimes this is an action taken prior to the crisis, such as the creation of a
simulator to use for testing if the hardware is late. At other times, it is a
simple backup plan, such as running a night shift to share hardware.
For the potential loss of a key person, for example, we might do two things:
Plan to reduce the impact by making sure other people become familiar with
that person’s work, or reduce the likelihood of attrition by giving the person a
raise, or by providing day-care.
Q5. Why is support software required in project management process? Explain some of
them
Ans:- Support Software
Having learnt the basics of Application software, students would have a fair
idea of how & to what extent PM Processes could be automated. However, the
challenge of “making things work” remains unchanged. While Software Vendors
are confident of “making it work”, two yawning gaps still remain – Business
Processes which are not covered in such Software & Integration of Multi vendor
supported software applications.
The Enterprise is normally in a dilemma – whether to look at the same vendors
to support such customization or not. This normally works out too expensive for
their comfort or within their tight budgets. Several Software Vendors have
seized the opportunity with offerings that substantially fill these gaps
effectively at a fraction of the costs quoted by the major vendors. The other
carrot which these vendors offer is a unilateral transfer of the facility to
customize them which is seen as a huge advantage. The various support
software that may be used for managing projects are:
ARROW
FEDORA
VITAL
PILIN
Why Fedora?
ARROW wanted a robust, well architected underlying platform, a flexible
object-oriented data model to be able to have persistent identifiers down to
the level of individual data streams. It accommodates the content model to be
able to be version independent.
VITAL
What is VITAL?
ARROW specified software created and fully supported by VTLS Inc. built on top
of Fedora that currently provides:
• VITAL Manager
• VITAL Portal
• VITAL Access Portal
• VALET – Web Self-Submission Tool
• Batch Loader Tool
• Handles Server (CNRI)
• Google Indexing and Exposure
• SRU / SRW Support
• VITAL architecture overview
Solution
Business Benefits
IT Benefits
The Microsoft Project family of products offers tools to work on a Project from
management point of view. Microsoft Project is designed for people who
manage projects independently and don’t require the capability to manage
resources from a central repository. Microsoft has a team project
management solution that enables project managers and their teams to
collaborate on projects.
After creating a fairly complete final project plan it is a good idea to create a
baseline to compare the original project plan with actual events and
achievements.
Tracking Progress
After creating a baseline, if the project has begun, it is necessary to enter
actual dates that tasks are being completed and the resource utilization used
to complete them. Again review different views and the cost and summary
tables before proceeding to the next section. Return to the Entry view of the
Gantt chart before proceeding.
Balancing Workloads
At times people and equipment can become assigned more work than they can
complete in normal working hours. This is called over allocation. Project can
test for this condition and reschedule (or level) their workload to accommodate
completing tasks during a normal day.
Monitoring Variances
After a baseline has been established and the project has begun, it is desirable
to determine if tasks are being accomplished on time and /or if cost over runs
are occurring.
Creating Reports
Project has many different built-in reports and has the capability building
custom reports and exporting data to other MS Office applications for
integration into other reporting venues.