"It is Possible to Give Without Loving But It Is Impossible To Love Without Giving"


You Are Invited Follow this Blog

Tuesday, 29 September 2015

Verse of the Day......

“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.’
Jeremiah 33:2-3 NIV

Friday, 11 October 2013

Writing structured Project Report

The Project Report

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

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

Title page
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 your progress.

Contents page
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 met...".

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.

Body of report
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 supervisor.

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.

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

I hope you will find this piece very useful, if so please drop me a line expressing your feelings about it.

Enjoy the reading and become one of us!

Sunday, 26 May 2013

The Must Know Tips for Project Communication
In a project environment, the circulation of unofficial information and rumours is enough to make heads spin. Some organisations set up official communication plans that 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 offline.
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 face-to-face.
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.
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"

When 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 strategy of 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 those initiatives.

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. 

Teamwork Increases

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

Profitability Rises

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

Opportunities Abound

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


Thursday, 10 January 2013

Fred Alfred invited you to check out Dropbox

Hi there,

Fred Alfred wants you to try Dropbox! Dropbox lets you bring all your photos, docs and videos with you anywhere and share them easily.

Get started here

- The Dropbox Team
To stop receiving invites from Dropbox, please go here.
Dropbox, Inc., PO Box 77767, San Francisco, CA 94107
© 2013 Dropbox

Wednesday, 9 January 2013

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 separately. 
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 to. 
5. Questionnaires
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 additional requirements.
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 the audience.


Tuesday, 13 November 2012

Wageni waalikwa wakihudhuria vikao vya ccm vinavyoendelea huko mjini Dodoma. Hilo bango hapo kushoto ni lugha gongana au naelewa vibaya?

Monday, 12 November 2012

Hi Reader,
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
The Project 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:
  1. Where do things currently stand with this project?
  2. What are the next steps on this project?
  3. What obstacles are in the way of this project coming to completion?
  4. What are the key metrics about this project?
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.
Best wishes