Anda di halaman 1dari 15

Undertake project planning

A critical element in the success of any project is the planning that


is undertaken at the onset of the project. In this topic will cover
important aspect of a project with a focus on the gathering of
information to determine what is required, breaking down those
requirements into manageable pieces and documenting the plan.
The documents that are generated will be used by a variety of
stakeholders who will need to use the documentation for a variety of
purposes depending on their relationship to the project. For example
developers need to know how long they have to develop something while
the business needs to know when to expect their new system.
The project plan is definitely the key document in the project. It is
a positive thing that represents the move from planning to execution.
It is simultaneously a tool for guiding management decisions, control,
and reporting. It tells you where you are, where you are going and how
you are going to get there.
The project planning process is almost always iterated several times.
For example, the initial draft may include generic resources and
undated duration while the final plan reflects specific resources and
explicit dates.
The project plan is used to:

 Document project planning assumptions


 Facilitate communications among stakeholders
 Guide project execution
 Document project planning decisions regarding to alternatives
chosen
 Provide a baseline for progress measurement and project control

To understand this you will need to:

 Plan information gathering activities to determine project


requirements, constraints and risk.
 Identify project partitioning on the basis of intended system
development life cycle and risk.
 Prepare project work breakdown, schedule and budget.
 Conduct a feasibility study and prepare a business case as
necessary.

Information Gathering
In the early stages of the project one of the most important things a
Project Manager can do is listen to those who are familiar with the
problem/opportunity. Once you have taken the time to read any
materials made available to you and identified the relevant
stakeholders seek their input into the definition of the
problem/opportunity.
You may need to use a variety of techniques to gain the information
you need, some examples of methods you may use are:

 Interviews
 Research
 Surveys
 Workshops

You need to plan your approach. Break down the information gathering
into logical sections, this might include for example:

 Understanding the business


 Understanding current systems
 Identifying potential process improvements
 Developing the new system concept

When discussing the problem/opportunity with stakeholders, whether in


an informal situation or formal meeting be sure to use open questions.
The following is an example that shows use of an open question as
opposed to a closed question:
 Closed Question – Do you think the project will have benefits for
your department?
 Open Question – What do you expect will be the benefits of the
project to your department?
An open question demonstrates:

 An interest in the project as a whole not just the due date,


allowing the client to include details about their feelings,
ideas and concerns
 A preparedness to listen to the client, respect for their input
 Your willingness to invest time
As a result of the open question the client will, it is hoped, provide
some substantial detail about the project which will promote the
discussion of issues, goals etc., thus initiating two-way
communication. The additional detail provided should enable you to
then ask further questions if necessary.
You will likely have covered questioning in another unit, now is a
good time to refresh your memory. There are many types of questions,
some other types you might use are:

 Close Questions require a simple response, often yes or no but


potentially a very brief answer.
 Direct Questions draw people into the conversation by singling
them out as the person responsible for answering the question
being asked.
 Probing Questions are used to follow up on something someone has
said, possibly to clarify something that has been said, or to
build on an idea.
 Leading Questions drive the discussion in a direction of your
choosing by suggesting what you want the answer to be in the
question itself,
 Hypothetical Questions help to promote consideration of things
that may have been overlooked.
 Indirect Questions aim to get everyone involved in the discussion
by opening the question to the whole group.
 Factual Questions can be used to confirm what you know already,
this is particularly useful when you have gained the information
from a source that you are not confident is reliable.
The following table contains a variety of questions. Indicate which
sample question (from the list below)applies to each question
listed:

Table 1
Questions type Matching Sample Questions
Direct Questions
Closed Questions
Factual Questions
Leading Questions
Indirect Question

Sample questions

- Is there a project budget?

- Lance, do you know whether there is a manual for the existing


software?

- So the total budget is $200,000 including GST.

- Any ideas for how we might involve the users in the approval
process?

- I presume you will want someone from the user group to be


involved in testing, have you considered who that might be?

It is not sufficient to plan time to gather information in isolation.


You need to allow time in your plan to sift and sort what you have
obtained, to cross check and summarize the information. Ultimately you
need consolidated, meaningful, accurate information that can be used
in future phases.
Summary of advantages and disadvantages of cloud computing
Advantages

Cost Savings

 Perhaps, the most significant cloud computing benefit is in terms


of IT cost savings. Businesses, no matter what their type or
size, exist to earn money while keeping capital and operational
expenses to a minimum. With cloud computing, you can save
substantial capital costs with zero in-house server storage and
application requirements.
Reliability

 With a managed service platform, cloud computing is much more


reliable and consistent than in-house IT infrastructure. Most
providers offer a Service Level Agreement which guarantees
24/7/365 and 99.99% availability.

Manageability

 Cloud computing provides enhanced and simplified IT management


and maintenance capabilities through central administration of
resources, vendor managed infrastructure and SLA backed
agreements. IT infrastructure updates and maintenance are
eliminated, as all resources are maintained by the service
provider.
Strategic Edge

 Ever-increasing computing resources give you a competitive edge


over competitors, as the time you require for IT procurement is
virtually nil. Your company can deploy mission critical
applications that deliver significant business benefits, without
any upfront costs and minimal provisioning time. Cloud computing
allows you to forget about technology and focus on your key
business activities and objectives.

Disadvantages

Downtime

 As cloud service providers take care of a number of clients each


day, they can become overwhelmed and may even come up against
technical outages. This can lead to your business processes being
temporarily suspended. Additionally, if your internet connection
is offline, you will not be able to access any of your
applications, server or data from the cloud.

Security

 The ease in procuring and accessing cloud services can also give
nefarious users the ability to scan, identify and exploit
loopholes and vulnerabilities within a system. For instance, in a
multi-tenant cloud architecture where multiple users are hosted
on the same server, a hacker might try to break into the data of
other users hosted and stored on the same server.
Vendor Lock-In

 Organizations may find it difficult to migrate their services


from one vendor to another. Hosting and integrating current cloud
applications on another platform may throw up interoperability
and support issues.
Limited Control

 Since the cloud infrastructure is entirely owned, managed and


monitored by the service provider, it transfers minimal control
over to the customer. The customer can only control and manage
the applications, data and services operated on top of that, not
the backend infrastructure itself.

Establish the IT project team


For this topic will cover material that relates to the
establishment of an IT project team for the project.
When the baseline project plan is approved there are many required
resources identified. There are seven fundamental resources types that
are required to implement almost any project. The actual quantity of
each resource should be identified in the detailed work breakdown
structure and schedules that make up the baseline project plan.
The seven fundamental types of resources are:

 People
 Money
 Equipment
 Facilities
 Materials and supplies
 Information
 Technology
Always start with the people first! Other materials and facilities are
useless without the right project team.
It is important that appropriate team members are selected to fill the
roles that have been identified during the project planning. Each team
member must be aware of what role they will play and what the
responsibilities of that role are. As a project manager you will need
to support the team throughout the project, ensuring that they have
the necessary skills and access to resources that might be required.
Resources in this context might include guidance, direction, review
and technical resources such as software or manuals. Teams form to
perform work as efficiently and effectively as possible. In order to
optimize their performance the team members need to interact with one
another appropriately and conform to expected standards. The team
should work together so that their complementary skills make the team
as a whole better than the sum of their individual skills, this only
occurs when the team wants to genuinely work together and where each
team member understands what is expected of them.

To understand this you will need to:

 Identify and select team members, including roles and


responsibilities, based on project solution requirements
 Determine training and support needs of team members
 Establish project team values and agreed behavioral standards
with team members
The project team is the group of people brought together to plan and
execute the project. The team will consist of a Project Manager and a
number of other resources who will be required to undertake the tasks
set out in the project plan. The number of team members and their
skills will be dependent on the project. The Project Manager will be
responsible for managing the team. They will develop the plan that is
to be followed and supervise the team performance against the plan.
The Project Manager will also need to assist the team in performing
their roles by supporting them through the course of the project. A
significant role for the Project Manager will be taking responsible
for ensuring that the project governance requirements are met. This
will include specific approvals throughout the course of the project,
some of which will result in the project stopping until the approval
is able to be achieved.
If the project is very large there may be a number of other leaders,
who are also team members, assigned roles on the project. These
leaders will assist the Project Manager with the management tasks for
the project. The roles of the leaders will vary from project to
project, they may be allocated roles that relate to specific skill
sets in the team.

Manage project execution activities

For this topic is related to the execution of the project. As the


project manager, you are responsible for ensuring that the project
goal and objectives are met. This is done by monitoring and managing
the project throughout the full project life cycle.
Management of this phase can be achieved by comparing the planned
status of the project to its actual status. If necessary, you can take
corrective action. You are responsible for the control of the human,
financial and physical resources. Critical to this phase is the
process of modifying work, objectives and expenditure in order to
complete a project successfully. This usually involves making changes
to the original plan, which is a normal part of managing projects.
You are also responsible for ensuring that stakeholders are kept
informed on the progress of the project and involved as appropriate.
Too much status information is not necessarily a good thing. Keeping
progress status reports simple and easy to read is the key to
effective status reporting. Distribution of the reports to the right
people is important. Stakeholders always have an interest in project
costs as well as the overall project activities.
Project team members need to know task completions and progress made
against task lists. All this needs to be done on a regular basis.
The following diagram shows how the process of management is applied
through the execution phase of the project:

To understand this you will need to:

 Monitor delivery and acceptance of assigned project team work


activities and manage individuals as necessary
 Monitor and control the quality of project deliverables
 Monitor and control project scope changes, risks and issues
 Manage system testing and hand-over activities

Coordinate project closure


You might wonder why you need to have a specific topic associated
with closing a project?
In this last topic you will come to understand that the closure of a
project is not as straightforward as it might seem. Right from the
beginning of planning the project you should focus on the target of
successfully closing the project. The project will have a finite
duration and you should want to ensure not only that the project has
been completed technically in a quality manner, but within budget and
schedule. Also the ongoing business after the project has been
completed should be as smooth as possible. As the project progresses,
you should develop a plan for its closure.
At any point in the project life cycle a project can be closed. Not
all projects are successful, as many as 30% of IT projects fail.
Closing an unsuccessful project that did not meet its objectives can
be very difficult and demoralizing for the project manager and project
team. In some cases it may be beneficial to replace the project team
with new people, who, having no emotional attachment to the project,
can close the project down quickly.

This phase is an important time to reflect on what it is that you have


learnt during the course of the project. Perhaps the lessons learnt
will ensure future projects are as successful as or even more
successful than this project was. In the event that the project was
not as successful as you had hoped, perhaps it was even a disaster, if
so then this phase will provide you with the opportunity to learn a
great deal.

To understand this you will need to:

 Prepare IT support plans and maintenance or support documents


 Obtain final project sign-off
 Conduct post-project review and document lessons learned
 Review and update disaster recovery plan
 Close project

Develop maintenance support documents


The outcome of many projects is a working system to be handed over to
some other organization to operate. The ease of future operation and
maintenance of such a network is probably specified among the
objectives for the project manager at the outset, but as the project
approaches completion the prospective network managers are likely to
take a progressively greater interest. If they do not do so of their
own accord then you need to activate them.

Support
You will need to develop appropriate support plans. These documents
will outline things like:

 What support is required? You will need to identify a variety of


things like:
o resources
o times (e.g. 24/7, business hours)
o mechanisms (e.g. help desk, application support number)
o prioritizing problems
 Key performance indicators
 Update release processes
 When will the support commence?
 How long will the support be available for?
 What if any budget issues are there?
 How will issues be managed (e.g. what if the issue logged is a
scope change)
 Who is responsible in the event of conflict during the support
phase?
 What logging and reporting requirements are there?
The following is an overview of some different types of support that
may be required:
Intensive short-term support
There will always be a period of intense support where the new system
is live but the vendor or development team still has some
responsibility for support to the client. During this time bugs may
emerge and need to be fixed quickly. Requirements may be debated and
negotiated as details that were not fully pinned down in the
requirements-gathering stage emerge while the client uses the system
in anger.
Ongoing support phase
Once the initial phase is completed, the risk that the system will
fail reduces and the involvement of the vendor reduces also. Bugs may
remain, but many of the issues from the client may suggest
enhancements, as a better understanding of the strengths and
weaknesses of the system emerge.
Post-implementation review
The post-implementation review is a very useful step in ongoing
maintenance. After a system has been running for three to six months,
it can be critically reviewed ideally by members of the implementation
team and those representing the client’s users. The aim is to
objectively evaluate the real benefits to accrue from the system, and
identify any possible improvements that could be made. Benefits relate
to future projects as lessons learnt and process to be implemented in
the future.

Maintenance
Before handover is completed ongoing short and/or long term
maintenance needs are to be finalised. This usually consists of
maintenance contracts and/or warranties. Maintenance contracts are
usually put in place for large systems to give the client assurances
about the likely cost of enhancements and the availability of
resources to develop them. This phase in the project life cycle is
often referred to as the maintenance phase: the term “maintenance”
applies to software as well as hardware. It refers to small
enhancements, bug fixes and large enhancements.
Service Level Agreements (SLA) are contracts put in place that outline
what support services are provided, what metrics are associated with
the services, and acceptable and unacceptable service levels. A
warranty is a guarantee that the product or system will function and
perform as specified. Warranties are often available for a set period
of time.

Develop project sign-off form


Once the project is completed the nominated representative or
representatives of the client need to accept the solution that has
been delivered. This is the formal project sign-off. The sign-off will
not generally occur until the product is complete and testing has been
finalized, see Conditional sign-off below for the exception to this.

Formal sign-off
Ideally any large or complex project should have a formal project
sign-off. The formal sign-off will occur only when the agreed
deliverables have been provided and accepted through verification
processes that will likely have been defined during the planning or
contract phase. For example the software will be accepted through
formal User Acceptance Testing as detailed in the Acceptance Test
Plan.
This sign-off should be an official document that clearly states:

 What is being accepted (perhaps including a list of key


components and/or version numbers)
 When the acceptance is occurring
 Who is accepting the product
 Typically the sign-off will include physical signatures.

Informal sign-off
An informal sign-off occurs when a set list of conditions is met. This
may be at a point in time, or when certain events have occurred as
defined in a contract or other agreement. For example if the project
involves setting up a network for a specific event (e.g. a conference)
then once the conference is over the project must be complete.
Conditional sign-off
Ideally a sign-off should be without condition, it should be at the
point in time that the client is absolutely satisfied that their needs
have been met. However this is not always possible. Sometimes there
are factors such as:

 Deadlines for release that cannot be moved (e.g. legislative


requirements)
 Contractual requirements
 A general acceptance that the solution will meet the client needs
with minimal intervention

In the event that there are a number of issues or known problems that
are being accepted into the production environment to be addressed
during the maintenance phase these may be listed as exceptions to the
sign-off. By providing a list of exceptions, if required, the project
can be officially concluded through the sign-off but with each party
aware of what is expected of it. It must also be clear what the
implications of this are, for example:

 If the final payment is due on sign-off is it being withheld in


whole or in part until the conditions are met?
 Is there are timeframe associated with the conditional sign-off?
 What will happen if the conditions are not met?

Outline steps in project closure (no more than 200 words)


Wala akong masagot ate jack !

A “Lesson learned” report describing good and bad of the project


including completion criteria and key performance indicators

One of the most important outputs from a project for a project


manager is the lessons learned. This is important as it allows you to
taken on board feedback from the project team, stakeholders and your
own experiences an build your skills by learning what you should do
again and what you should not do. You will have identified things
through the completion of your closure reports, but you should also
specifically focus on what can be learned.
Ask yourself questions like:

 What was done well? What could have been done better?
 Were the project goals met? If not why?
 Would you do things differently if you started the project today?
 Were there things in the project plan that were estimated poorly?
Were there any significant tasks not in the plan that you had to
complete to execute the project?
 Could you have improved communication to enhance the project?

There are no benefits to ignoring what could have been done better.
By learning from your experience you can enhance your skills and then
even if the project was not a success something positive can come out
of it.

The post completion report is conducted to find out whether the


promised benefits have been delivered and, if not, what should be done
to achieve them. The best time to carry out such a review is as soon
as possible after the project has had time to start showing the
planned benefits. For example, if a promised benefit was to reduce the
number of collusions on a network, this should be noticeable at the
completion of the project, whereas a planned benefit of increased
market share may take some months to realize.

Anda mungkin juga menyukai