“This is what the LORD says, he who made the earth, the LORD who formed
it and established it—the LORD is his name: ‘Call to me and I will
answer you and tell you great and unsearchable things you do not know.’
The project report is
an extremely important aspect of the project. It should be properly structured
and also necessary and appropriate information regarding the project. No data
fields are to be exposed in the project field.
The aim of the
project is to achieve a specific objective with a particular time frame and
within defined budget framework. The project design document has to be
progressively converted to a project report as and when the various stages of
project are completed. Ideally you should produce the bulk of the report as you
go along and use the last week or two to bring it together into a coherent
to go about writing Project Report
A tidy, well laid out
and consistently formatted document makes for easier reading and is suggestive
of a careful and professional attitude towards its preparation. Remember that
quantity does not automatically guarantee quality. A 150 page report is not
twice as good as a 75-page one, nor a 10,000 line implementation twice as good
as a 5,000 line one. Conciseness, clarity and elegance are invaluable qualities
in report writing, just as they are in programming, and will be rewarded
appropriately. Try to ensure that your report contains the following elements,
however the exact structure, chapter titles etc. is in your discretion.
This should include the
project title and the name of the author of the report. You can also list the
name of your supervisor if you wish.
The abstract is a very
brief summary of the report's contents, it is sometimes known as executive
summary. It should be about half a page long. Somebody unfamiliar with your
project should have a good idea of what it's about having read the abstract
alone and will know whether it will be of interest to them.
It is usual to thank
those individuals who have provided particularly useful assistance, technical
or otherwise, during your project. Your supervisor will obviously be pleased to
be acknowledged as he or she will have invested quite a lot of time overseeing
This should list the
main chapters and (sub)sections of your report. Choose self-explanatory chapter
and section titles and use double spacing for clarity. If possible you should
include page numbers indicating where each chapter/section begins. Try to avoid
too many levels of subheading - three is sufficient.
This is one of the most
important components of the report. It should begin with a clear statement of
what the project is about so that the nature and scope of the project can be
understood by a lay reader. It should summarise everything you set out to
achieve, provide a clear summary of the project's background, relevance and
main contributions. The introduction should set the context for the project and
should provide the reader with a summary of the key things to look out for in
the remainder of the report. When detailing the contributions it is helpful to
provide pointers to the section(s) of the report that provide the relevant technical
details. The introduction itself should be largely non-technical. It is useful
to state the main objectives of the project as part of the introduction.
However, avoid the temptation to list low-level objectives one after another in
the introduction and then later, in the evaluation section (see below), say
reference to like "All the objectives of the project have been
The background section
of the report should set the project into context and give the proposed layout
for achieving the project goals. The background section can be included as part
of the introduction but is usually better as a separate chapter, especially if
the project involved significant amount of ground work. When referring to other
pieces of work, cite the sources where they are referred to or used, rather
than just listing them at the end.
The central part of the
report usually consists of three or four chapters detailing the technical work
undertaken during the project. The structure of these chapters is highly
project dependent. They can reflect the chronological development of the
project, e.g. design, implementation, experimentation, optimisation, monitoring,
evaluation etc. For example if you have designed a new consumer product you
should describe and justify the design of your product at some high level,
possibly using an approved graphical representation such as diagram or picture.
It should also document any interesting problems with, or features of, your
implementation. Integration and testing are also important to discuss in some
cases. You need to discuss the content of these sections thoroughly with your
Be warned that many
projects fall down through poor evaluation. Simply designing a new product and
documenting its design and functionality is not enough to gain top marks. It is
extremely important that you evaluate what you have done both in absolute terms
and in comparison with existing techniques and other products in the market.
This might involve quantitative evaluation and qualitative evaluation such as
expressibility, functionality, ease-of-use etc. At some point you should also
evaluate the strengths and weaknesses of what you have done. Avoid statements
like "The project has been a complete success and we have solved all the
problems associated with ...! It is important to understand that there is no
such thing as a perfect project. Even the very best pieces of work have their
limitations and you are expected to provide a proper critical appraisal of what
you have done.
and Future Work
The project's conclusions
should list the things which have been learnt as a result of the work you have
done. Avoid tedious personal reflections like "I learned a lot about product
design using a particular techniques." It is common to finish the report
by listing ways in which the project can be taken further. This might, for
example, be a plan for doing the project better if you had a chance to do it
again, turning the project deliverables into a more polished end product.
This consists of a list
of all the books, articles, manuals etc. used in the project and referred to in
the report. You should provide enough information to allow the reader to find
the source. In the case of a text book you should quote the name of the
publisher as well as the author(s). A weakness of many reports is inadequate
citation of a source of information. It's easy to get this right so there are
no excuses. Each entry in the bibliography should list the author(s) and title
of the piece of work and should give full details of where it can be found.
The appendices contain
information which is peripheral to the main body of the report. Information
typically included are things like parts of the code, tables, test cases or any
other material which would break up the theme of the text if it appeared in
situ. You should try to bind all your material in a single volume and create
the black book.
hope you will find this piece very useful, if so please drop me a line
expressing your feelings about it.
In a project environment, the circulation of unofficial
information and rumours is enough to make heads spin. Some organisations set up
officialcommunication plansthat detail who knows what and when,
but struggle with managing the unofficial information. The following are tips
to stop the confusion and manage the grapevine effectively:
Tip 1 - Become Part of the Grapevine
People love talking about what goes on
within their work environment. The grapevine truly does exist in all companies.
Assume the projects you manage are one part of that conversation, insert
yourself into it and ask people what they are hearing about your projects. Is
there any news from above? Are resources happy? Then, be sure to add your own
facts into the mix. A little bit of accurate information never hurt anyone.
Tip 2 - Combat Negative Messages with Facts
Negative communication sometimes gets
spun into a mile-long email thread. Inaccurate information and intensity of
emotion continue to escalate the longer the email thread grows. The best
antidote to negative communication is to get the facts out there as quickly as
possible. Compose a thoughtful and precise "Reply All" with a handful
of relevant facts to get everyone in sync. Then, kill the thread and take it
Tip 3 - Stop the Bad Press
Most talk on the grapevine is harmless,
primarily serving as an interesting diversion during a long day at work. People
don't really pay that much attention to it. However, innocuous gossip can turn
into hurtful and malicious slander. You need to track down the source of that
information immediately and make it stop. Find out why someone feels compelled
to put forth such negative propaganda about your project and deal with it
Tip 4 - Fill the Vacuum
You may have projects that aren't
impacted by negative communication. However, you are left with a vacuum of
communication. It's up to you to fill this void with positive and factual
information about your project. Send out pertinent emails, give appropriate
updates at company meetings, and have one-off conversations. That way, people
will really have something to talk about when your project gets tangled up in
The grapevine has been around since the time the 3rd person
walked on this Earth. There's nothing you can do to stop it from happening, so
include it as part of your unofficial communication plan. You'll notice a big
difference with the buzz on your projects.
Dear friends, it is such long time since I posted something for you, I really apologise for the inconveniences this might have caused. I am now back and will be available for giving or sharing with you what you might need for your projects' smooth landing. Today, I have what I termed
"The Power of the Aligned Organization"
was the last time you rode in a car with wheels that were not properly aligned?
Chances are it was a pretty rough ride. The car either pulled in one direction,
making it hard work to keep it in your lane, or, it worked against itself as
one tire pointed one way and another tire another way.
The same thing can happen in our companies. The ride can be pretty bumpy, not
to mention noisy,unless everyone
is pointed in the same direction.That’s
why it’s important to understand the benefits of an aligned organization as
they presented below:
Ensures Everyone Works on the Right Things
The first benefit of an aligned organization is that with a common goal for
everyone to strive towards, the right things are worked on. Here’s the trick -
you need make sure that everyone clearly understands the goal and the end game.
The best way to accomplish this is to clearly communicate the strategyof the company. What are the three to
five most important things your company is working on? Once those are
communicated and understood, you can then align everyone’s activity to accomplish
More is Accomplished
An aligned organization is structured and disciplined. This doesn’t mean the
company lacks creativity or is oppressive. Rather, it means that projects not
aligned with company strategy are not allowed to infiltrate the company.
Alignment allows resources to stay focused on the tasks at hand and not waste
time on other distractions.
A third benefit of alignment in the organization is increased camaraderie. The
‘us’ versus ‘them’ mentality is nipped in the bud while everyone works toward
the same goals together. Departments and groups of people that are not properly
aligned have a tendency to look after their own interests. This will still
occur in the aligned organization, but there is also more of, “what can I do to
help?” Team members in the aligned organization realize that everyone must
cross the finish line at the same time in order for the project to be
aligned company is a company that runs efficiently. Engaged teams that are
working on the right things are naturally going to get more done. Getting more
done in less time results in increased profitability. There are fewer
misunderstandings and mistakes - and rework is few and far between. Alignment
helps keep resource costs in check, and reduces expenses, both of which are
areas that impact the bottom line.
like working with people and companies that have a track record of success. The
aligned organization will have plenty of success stories to tell. That
credibility allows salespeople to sell more, executives to explore new
strategies, and managers to optimize opportunities. It generates more top-line
revenue that ultimately trickles down to the bottom line.
A car that is not aligned will still run; however, the ride is rough and it’s
not very efficient on gas. Once aligned, the car rides much more smoothly and
fuel efficiency increases dramatically. Your company can still run if it’s not
aligned, just not very efficiently. Take the time to align your organization
and begin realizing the benefits!
Wish you successful implementation of your project.
Hi visitors, first
of all I am obliged to say Happy New Year To you all. I must believe that we
all have crossed over from 2012 to 2013 without carryovers. Today, I have got
some interesting issues that you are project manager/owner need to know.
Understanding requirements is one of the key
elements for project success. Elicitation is the part of the requirements
gathering process where you actually capture the client needs. There are a
number of techniques for eliciting requirements. Your project may need to use
multiple techniques depending on the circumstances. Below am presenting
to you the most important seven Techniques for Gathering (eliciting) Requirements
1. One-on-one interviews The most common technique for gathering
requirements is to sit down with the clients and ask them what they need.
2. Group interviews These are similar to the one-on-one interview
except that there is more than one person being interviewed. Group interviews
require more preparation and more formality to get the information you want
from all the participants.
3. Facilitated sessions
In a facilitated session, you bring a larger group together for a common
purpose. In this case, you are trying to gather a set of common requirements
from the group in a faster manner than if you were to interview each of them
4. JAD sessions Joint Application Development (JAD) sessions are
similar to general facilitated sessions. However, the group typically stays in
the session until a complete set of requirements is documented and agree
These are good tools to gather requirements from stakeholders in remote
locations or those that will have only minor input into the overall
requirements. It can also be the only practical way to gather requirements from
dozens, hundreds or thousands of people.
6. Prototyping Prototyping is a way to build an initial version
of the solution – a prototype. You show this to the client, who then gives you
7. Following people around This is especially helpful when gathering information
on current processes. You may need to watch people perform their job before you
can understand the entire picture. In some cases, you might also like to
participate in the actual work process to get a hands-on feel for how the
business function works today.
Knowing your audience will help you determine the
right techniques to utilize to best meet your needs. You should select
techniques that get you the most relative information and are best suited for
Most companies have enough reports
to go around for everyone on your team to have at least two or three of their
own. But, every report takes time to put together, time to maintain, time to
read, and time to act upon.
It's your job as a project manager
to get to the heart of what is important for project stakeholders to know. To
accomplish this below are the:
Top 5 Types of Project Reports
Entire forests could be destroyed if
we printed out all the various reports we receive each day to manage our
projects. Many reports end up being either auto-forwarded to the Trash bin or
they are manually deleted them any time they show up in the Inbox.
Focus on what's important by zeroing
in on these top 5 types of project reports:
Report 1: The Project Status Report
Status Report does just that...it provides the general status of the
project. This mid-level report should be detailed enough to answer questions
about the current health of the report yet not-so detailed that people who read
it are lulled to sleep with trivial details. This report should answer the
following four questions:
Where do things currently stand
with this project?
What are the next steps on this
What obstacles are in the way
of this project coming to completion?
What are the key metrics about
Report 2: The Risk Register
The risk register, or summary of the
risk register, is another vital report you want to create. Risks are always
lurking in the background of any project just waiting to knock it off course.
The risk register identifies those risks, quantifies the potential negative
impact they could have on a project, and then offers mitigations plans for each
of the identifies risks.
A summary of the risk register could
feed directly into the Project Status report as one of the key metrics. For
example, you could show the total number of risks that are still open on a
project and categorize these by severity. This will give the reader of the
report a good indication as to the general state of risk that is associated
with each project.
Report 3: The Issue Log
The issue log report is your way of
dealing with risks that have either come to realization or an unexpected event
occurred. For example, the risk may have been that a particular key resource
could find another job and delay the project. The Issue is now that the project
is delayed because that resource did find another job. Or, an issue may be an
unexpected event such as a coding issue on a software deployment that brought
the software to a grinding halt.
This report should show what is ACTIVELY
being done to address each issue and prioritize them by area of impact on the
project. This can range from "Showstopper" to "Minor
Cosmetic" and will then serve as the marching orders for everyone to
follow in order to get the project back on track.
Report 4: The Executive Summary
The Executive Summary is a very
unique report that is written in a different language than the reports
mentioned above. The Executive Summary is a high-level report that can provide
a solid understanding of the project status, benefits it will yield, how the
project fits into future strategies, and ultimately improves the bottom line of
the company. This is written in the mindset of a busy executive who has moments
to spend on one of many projects and initiatives that are under their purview.
Keep this report objective and
factual. Paint a realistic picture as executives know that everything does not
always go as planned. They just want to know that you have a plan for how to
corral the project back to where it belongs.
Report 5: Whatever you Want
This is not meant to be a flippant
statement. What it is meant to be is a reflection on reality. The reality is
that it is hard to have just the right report for every company, project,
circumstance, or audience. It's up to you as the project manager to combine the
best aspects of each report and come up with whichever one works for you.
You'll learn over time which pieces of information are relevant on a report and
get the most action and reaction from those who read them.
Make sure this report is easy to
generate week after week. You want to spend more time working on what the
report tells you rather than working on the report itself.