QAB Mod 1 Introduction to Projects
QAB Mod 1 Introduction to Projects
1
2. Will this person encourage project team members to bring up problems rather than play the
blame game?
3. Does this person have excellent time management skills?
Organizational Experience
1. Does this person know how work gets done in this organization?
2. Is this person experienced in working in similar organizations and is that experience
transferable to this project?
3. Does this person know the politics of our organization and have the savvy to navigate these
situations?
Skills and Knowledge
1. Does this person have adequate knowledge about the subject of this project?
2. If some of these skills are weak is there support available in the organization to offset the
problem?
3. Does this person have adequate technical skills for this project?
4. Does this person have the skills understand the root causes of potential problems and keep
them from reoccurring?
Project Management Experience
1. Has this person led projects of similar scope, size, length and priority?
2. Is this person on a growth track to lead more complex projects?
2
Q8. Describe the 7S of project management.
Ans. A recent (2008) update on the McKinsey 7S model is a short podcast on the creation
of McKinsey 7S model by Lowell Bryan, a director in McKinsey’s New York office, involved in
creating and applying the 7S framework. He describes how it was introduced in the late 1970s to
address the critical role of coordination, rather than structure, in organizational effectiveness.
3
1. They must be technically competent. This is so obvious that it is often the only criterion
applied. While the functional departments will always remain the ultimate source of
technological problem solving for the project, it requires a technically competent person to
know exactly when additional technical knowledge may be required by the project.
2. Senior members of the project team must be politically sensitive. It is rarely possible to
complete a project of reasonable size and complexity without incurring problems that
require aid from the upper echelons of executive row; that is, from a project champion
(Pinto and Slevin, 1989). Getting such aid depends on the PM’s ability to proceed without
threatening, insulting, or bullying important people in the functional groups. To ensure
cooperation and assistance, there is a delicate balance of power that must be maintained
between the project and the functional departments, and between one project and others.
3. Members of the project team need a strong problem orientation. This characteristic will be
explained in more detail shortly. For now, take the phrase to mean that the team’s members
should be concerned about solving any problems posed by the project, not merely about
those sub problems that concern their individual academic or technical training.
4. Team members need a strong goal orientation. Projects are uncomfortable environments
for people with a 9 to 5 view of work. In particular, neither project teams nor PMs can
succeed if their focus is on activity rather than results. On the other hand, the project will
not be successful if the project team dies from overwork. One project team member of our
acquaintance was bemoaning a series of 60+ hour weeks. “They told me that I would work
about 50 hours in an average week. I’ve been on this project almost 18 months, and we
haven’t had an average week yet.”
5. Project workers need high self-esteem. Project members who hide mistakes and failure are
disasters waiting to happen. Team members must be sufficiently self-confident and have
sufficient trust in their fellow team members (Lencioni, 2002) that they can immediately
acknowledge their own errors and point out problems caused by the errors of others. PMs
should note that “shooting the messenger” who brings bad news will instantly stop the
flow of negative information. The result is that the golden rule we stated above, “Never let
the boss be surprised,” will be violated, too.
In this phase, the current or prospective project leader writes a proposal, which contains a
description of the above-mentioned matters. Examples of this type of project proposal include
business plans and grant applications. The prospective sponsors of the project evaluate the
proposal and, upon approval, provide the necessary financing. The project officially begins at the
time of approval. Questions to be answered in the initiation phase include the following:
4
(a) Why this project?
(b) Is it feasible?
(e) What are the boundaries of this project (what is outside the scope of the project)?
In the initiation phase, the project partners enter a (temporary) relationship with each other. To
Notes prevent the development of false expectations concerning the results of the project, it makes
sense to explicitly agree on the type of project that is being started:
The choice for a particular type of project largely determines its results.
Example: A research and development project delivers a report that examines the technological
feasibility of an application. A project in which a prototype is developed delivers all of the
functionalities of an application, but they need not be suitable for use in a particular context (e.g.
by hundreds of users). A project that delivers a working product must also consider matters of
maintenance, instructions and the operational management of the application.
5
involved in developing graphic material, contractors are building, and the actual reorganization
takes place. It is during this phase that the project becomes visible to outsiders, to whom it may
appear that the project has just begun. The implementation phase is the doing phase, and it is
important to maintain the momentum.
In one project, it had escaped the project teams’ attention that one of the most important team
members was expecting to become a father at any moment and would thereafter be completely
unavailable for about a month. When the time came, an external specialist was brought in to take
over his work, in order to keep the team from grinding to a halt. Although the team was able to
proceed, the external expertise put a considerable dent in the budget.
At the end of the implementation phase, the result is evaluated according to the list of
requirements that was created in the definition phase. It is also evaluated according to the designs.
Example: Tests may be conducted to determine whether the web application does indeed support
Explorer 5 and Firefox 1.0 and higher. It may be determined whether the trim on the building has
been made according to the agreement, or whether the materials that were used were indeed those
that had been specified in the definition phase. This phase is complete when all of the
requirements have been met and when the result corresponds to the design.
The central question in the follow-up phase concerns when and where the project ends. Project
leaders often joke among themselves that the first ninety per cent of a project proceeds quickly
and that the final ten per cent can take years. The boundaries of the project should be considered in
the beginning of a project, so that the project can be closed in the follow-up phase, once it has
reached these boundaries.
It is sometimes unclear for those concerned whether the project result is to be a prototype or a
working product. This is particularly common in innovative projects in which the outcome is not
certain. Customers may expect to receive a product, while the project team assumes that it is
building a prototype. Such situations are particularly likely to manifest themselves in the follow-
up phase. Consider the case of a software project to test a very new concept.
There was some anxiety concerning whether any results would be produced at all. The project
eventually produced good results. The team delivered a piece of software that worked well, at least
within the testing context. The customer, who did not know much about IT, thought that he had
received a working product. After all, it had worked on his office computer. The software did
6
indeed work, but when it was installed on the computers of fifty employees, the prototype began
to have problems, and it was sometimes instable.
Did u know Gantt Charts have been around for over a hundred years. The discipline of project
management has evolved and been refined for longer than you might suspect.