IT Project Management - Best Practices

User Centered Design

2009-03-28T09:00:00.001-07:00

User Centered Design answers questions about users and their tasks and goals, then use the findings to make decisions about development and design. It seeks to answer the following questions:

* Who are the users of the document?
* What are the users’ tasks and goals?
* What are the users’ experience levels with the document, and documents like it?
* What functions do the users need from the document?
* What information might the users need, and in what form do they need it?
* How do users think the document should work?

Developing High Performance Team

2009-03-17T00:18:00.000-07:00

1. Ensure Team composition matches tasks

2. Clearly define the project and team purpose

3. Clearly define team members role, leveraging unique skills and talent

4. Clearly define team member's responsibility to the team

5. Create clear guidelines for deliverables

6. Work as a Team to define team culture and identity

7. Work as a Team to develop problem solving and conflict resolution guidelines

8. Create an Environment that fosters respect and courtesy

9. Recognize individual and group achievements

10. Manage Team time efficiently

11. Establish Communications Guideline

12. Implement Technology to enhance real time communication and collaboration

Software Test Strategy

2009-03-16T02:21:00.000-07:00

In this strategy we assume that it's undoable to test everything. From a economic point of view it doesn't even make sense; spending lots of time to parts of a system where the chances of having a bug are low, or even if a bug has been found, where the impact of it will be low. Risk and requirements based testing helps you to determine what to test first, in which sequence, so you spend the time you have to the parts that really matter.

The strategy starts with a risk analysis to determine the functions (requirements) with the highest risk, and plan your test activities guided by this analysis.

To help you identify the risks involved in all your requirements, consider the following aspects:

Functions often used by the users
Complex functions
Functions that have a lot of updates or bug fixes
Functions that require high availability
Functions that require a consistent level of performance
Functions that are developed with new tools
Functions that require interfacing with external systems
Functions with requirements with a low level of quality
Functions developed by more programmers at the same time
New functions
Functions developed under extreme time pressure
Functions that are most important to the stakeholders
Functions that reflect a complex business process

Risk Checklist

2009-03-16T01:56:00.000-07:00

1. Stakeholders

Have you identified all stakeholders?
Have you identified from all groups the leader or spokesman?
Have you ever met the stakeholders?
Do you have information on the background of the stakeholders (history)?

1.1 Stakeholder's Fears
Do you know what the fears are generally for the type of stakeholders you have (e.g. programmers)?
Do you know what the fears are of the stakeholders per group?
Do you know what the fears are for each individual?
Do you know how this project affects the fears of the stakeholders?

1.2 Stakeholder's Wishes
Do you know what the wishes are generally for the type of stakeholders you have (e.g. programmers)?
Do you know what the wishes are of the stakeholders per group?
Do you know what the wishes are for each individual?
Do you know how this project affects the wishes of the stakeholders?

2. Requirements

2.1 Product

Are the cause and goal of the project clear to you?
Is the project scope identified and does it include what you can change, what you must change, and what you can't change?

2.2 Process

Are the constraints identified (money, time, people)?
Do you have any idea how much room there is to negotiate these constraints?
If there are already estimations, do you know how much you can trust them?
Is the project strategy clear and easy?
Is the project organisation identified? Does every member have added value to the project?

3 Project management

Are you able to negotiate?
Are you able to think in win-win situations?
Are you risk averse?
Do you include your own stakes into the process?
Are you able to give the project back in case it smells like a trap?

2.4 Feedback

Is everyone aware for the need and use of giving feedback?
Have you any idea how to provide feedback?
Do you really understand the techniques you want to use?
Did you schedule (time, money, people) activities to provide the feedback?

10 key principles of Agile Software Development

2009-03-16T00:18:00.001-07:00

1. Active User Involvement
It is imperative to have a senior and experienced user representative involved throughout. The benefits are:

Requirements are clearly communicated and understood (at a high level) at the outset
Requirements are prioritised appropriately based on the needs of the user and market
Requirements can be clarified on a daily basis with the entire project team, rather than resorting to lengthy documents that aren't read or are misunderstood
Emerging requirements can be factored into the development schedule as appropriate with the impact and trade-off decisions clearly understood
As iterations of the product are delivered, that the product meets user expectations
The product is more intuitive and easy to use
Developers are accountable, sharing progress openly with the user/business every day
The user/business shares responsibility for issues arising in development; it’s not a customer-supplier relationship but a joint team effort
Timely decisions can be made, about features, priorities, issues, and when the product is ready
Responsibility is shared; the team is responsible together for delivery of the product
Individuals are accountable, reporting for themselves in daily updates that involve the user/business

2. Agile Development Teams Must Be Empowered
The project team must be empowered to make decisions in order to ensure that it is their responsibility to deliver the product and that they have complete ownership. Any interference with the project team is disruptive and reduces their motivation to deliver.

The team must establish and clarify the requirements together, prioritise them together, agree to the tasks required to deliver them together, and estimate the effort involved together.

3. Requirements evolve but the timescale is fixed
In Agile Development, requirements evolve, but timescales are fixed. In Agile Development projects, requirements are allowed to evolve, but the timescale is fixed. So to include a new requirement, or to change a requirement, the user or product owner must remove a comparable amount of work from the project in order to accommodate the change.

4. Capture requirements at a high level; lightweight & visual
Agile Development teams capture requirements at a high level and on a piecemeal basis, just-in-time for each feature to be developed. Agile Development teams can build better products if they have a reasonably clear idea of the overall requirements before setting out on development, so that incorrect design decisions don’t lead the team down dead ends and also so a sensible investment case can be made to get the project funded.

However any requirements captured at the outset should be captured at a high level and in a visual format, perhaps for example as a storyboard of the user interface. At this stage, requirements should be understood enough to determine the outline scope of the product and produce high level budgetary estimates and no more.

5. Develop small, incremental releases and iterate
One bite at a time! Likewise, agile software development projects are delivered in small bite-sized pieces, delivering small, incremental *releases* and iterating.

6. Focus on frequent delivery of products
Agile software development is all about frequent delivery of products. In a truly agile world, gone are the days of the 12 month project. In an agile world, a 3-6 month project is strategic!

But how frequent is *frequent*?

Scrum says break things into 30 day Sprints. That's certainly frequent compared to most traditional software development projects.

Consider a major back-office system in a large corporation, with traditional projects of 6-12 months+, and all the implications of a big rollout and potentially training to hundreds of users. 30 days is a bit too frequent I think. The overhead of releasing the software is just too large to be practical on such a regular basis.

But consider a web site, a web-based product - or even more dynamic something like my blog. There's no rollout overhead - it's an automated central deployment to all users, and for the blog it's a single click. No-one's paying for the service. If something's wrong, no-one dies. And it can be rolled back as quickly as it's deployed. There may be thousands of users, even millions of users of a web site every month. But none of them need to be trained. And you can evaluate the impact on the user experience, and the user's behaviour, through metrics within 24 hours and on an ongoing basis.

So how frequent is *frequent enough*?

Think carefully about your own situation. Think about the two extremes I've described above. Think about what's right for you; your organisation; your product; your market; your customers. Think about what's right for *you*, in your *particular situation*. There is no right or wrong answer. Only what works for you, and what doesn't.

7. Complete each feature before moving on to the next
In agile development, "done" should really mean "DONE!".

Features developed within an iteration (Sprint in Scrum), should be 100% complete by the end of the Sprint.

In an ideal situation, each iteration or Sprint should lead to a release of the product. Certainly that's the case on BAU (Business As Usual) changes to existing products. On projects it's not feasible to do a release after every Sprint, however completing each feature in turn enables a very precise view of progress and how far complete the overall project really is or isn't.

8. Apply the 80/20 rulePareto's law is more commonly known as the 80/20 rule. The theory is about the law of distribution and how many things have a similar distribution curve. This means that *typically* 80% of your results may actually come from only 20% of your efforts!

9. Testing is integrated throughout the project lifecycle – test early and often
In agile development, testing is integrated throughout the lifecycle; testing the software continuously throughout its development.

Agile development does not have a separate test phase as such. Developers are much more heavily engaged in testing, writing automated repeatable unit tests to validate their code.

10. A collaborative & cooperative approach between all stakeholders is essential
Agile development relies on close cooperation and collaboration between all team members and stakeholders. Agile development principles include keeping requirements and documentation lightweight, and acknowledging that change is a normal and acceptable reality in software development.

This makes close collaboration particularly important to clarify requirements just-in-time and to keep all team members (including the product owner) 'on the same page' throughout the development.

What makes a good Project Manager?

2009-03-15T10:25:00.000-07:00

by Deborah Bigelow, PMP

From recent articles and highlights of successful projects, there appears to be some common threads woven into the personalities of successful PMs:

Love of their work … and embracing the challenges
Clear vision … and communicating this vision
Strong team building skills…and setting positive tones
Structure and alignment…creating the environment and direction
Strong interpersonal skills…listening to and leading their teams
Discipline…completing each phase of the project properly
Communication skills…knowing when and to whom to communicate

Frank Toney reports in the newsletter Project Management Best Practices Report that a study of The Top 500 Project Management Benchmarking Forum identified traits of a best practice project manager.

According to the study, the best PMs:

are recognized by stakeholders as the single most important factor in project goal achievement
are truthful in all dealings and relationships
exhibit eagerness to organize and lead groups
exhibit evidence of a strong desire for goal achievement
are even-tempered
have faith that the future will have a positive outcome
have confidence their personal performance will result in a positive outcome

These champions bring a can-do structure and discipline to organizations, helping them transform informal processes into a project management culture and force. A recent article in Compuworld featured a story of a senior vice president of a Fortune 500 organization. This VP's project management staff initially resisted his program of discipline, structure, tools, training, and leadership. They were accustomed to mediocrity. But as his staff became more effective at their jobs, they realized his way was better. In fact, he and his team of 25 were able to reduce the project cycle time 15% to 25% and cut personnel expenses by 10% per year while taking on bigger and more complex projects. The “Expert Series” is a collection of articles, papers and writings by PM Solutions’ associates and other industry experts that provides insight into the practice and value of project management.

Why do IT projects fail?

2009-03-15T09:45:00.000-07:00

1. Project Initiation and Planning Issues

Unclear or unconvincing business case
Insufficient or non-existent approval process
Poor definition of project scope and objectives
Insufficient time or money given to project
Lack of business ownership and accountability
Insufficient and/or over-optimistic planning
Poor estimating
Long or unrealistic timescales; forcing project end dates despite best estimates
Lack of thoroughness and diligence in the project startup phases

2. Technical and Requirements Issues

Lack of user involvement (resulting in expectation issues)
Product owner unclear or consistently not available
Scope creep; lack of adequate change control
Poor or no requirements definition; incomplete or changing requirements
Wrong or inappropriate technology choices
Unfamiliar or changing technologies; lack of required technical skills
Integration problems during implementation
Poor or insufficient testing before go-live
Lack of QA for key deliverables
Long and unpredictable bug fixing phase at end of project

3. Stakeholder Management and Team Issues

Insufficient attention to stakeholders and their needs; failure to manage expectations
Lack of senior management/executive support; project sponsors not 100% committed to the objectives; lack understanding of the project and not actively involved
Inadequate visibility of project status
Denial adopted in preference to hard truths
People not dedicated to project; trying to balance too many different priorities
Project team members lack experience and do not have the required skills
Team lacks authority or decision making ability
Poor collaboration, communication and teamwork

4. Project Management Issues

No project management best practices
Weak ongoing management; inadequately trained or inexperienced project managers
Inadequate tracking and reporting; not reviewing progress regularly or diligently enough
Ineffective time and cost management
Lack of leadership and/or communication skills

Project Success Factor

2009-03-15T09:25:00.000-07:00

Identify which of these success factors are missing in your project and ask why - this will help you plan for risk mitigation action.

1. Executive Support
This is the number one important factor. If executives are not supportive, they're unlikely to assign needed resources (labour hour, dollars, equipment etc) to the project. Additionally, they are less likely to defend the project if it runs into trouble or gets bogged down by corporate politics.

2. User Involvement
Many IT managers find it difficult to involve users early on for two key reasons. First, users are typically uneducated about IT processes, whether it's software development or infrastructure upgrades. Without understanding how things work in IT, most users come up with fairly unrealistic expectations about how and when things should be done.

A second big complaint from the IT department is scope creep - the requirements for the project keep growing even as the project is underway. On the other side, users complain that they are left out of the loop until it's too late to make any changes to the project.

From a user's perspective, the IT department often comes in, asks a few questions and months later unveils the new system, application, or solution. Users are not asked about requirements ahead of time, are often not involved in usability and functionality testing, and sometimes not trained until after the fact.

3. Experienced Project Manager
There are strong evidence that having a trained, experienced project manager has an enormous impact on a project's chance of success. In fact, according to the Standish Group's research, 97% of all successful projects have an experienced project manager.

4. Clearly Defined Project Objectives
There are a number of reasons why projects lack defined objectives. Laziness is one explanation, of course, but not the best one. Most of the time there are numerous organizational factors including politics, shifting priorities, cash flow/financial problems, extremely tight timelines, and organization restructuring that sometimes make defining project objectives difficult or impossible. Project objectives essentially define the scope of the project.

5. Clearly Defined (and Smaller) Scope
Studies have shown that the longer a project runs (scheduled duration), the less likely it is to be successful, so there is an inverse relationship between project success and time.

6. Shorter Schedules, Multiple Milestones
Milestones are simply markers to help you navigate through your project plan and indicate important checkpoints or events. The sooner you notice the project is heading off-course, the easier it is to make small adjustments. It makes sense, then, that the more often you have a checkpoint, the more successful your project is likely to be.

7. Clearly Defined Project Management Process
A clearly defined project management process is important for project success for several reasons. First, when processes are clearly defined, you avoid reinventing the wheel each time and you can re-use processes that worked and tweak those that didn't. Also, clearly defined processes reduce or eliminate some of the project re-work.

8. Standard Infrastructure
Standardizing the infrastructure of the code's foundation leads to both efficiency and stability in the code. Some of the infrastructure code is unique to the application, but often there are components that can be purchased from an infrastructure vendor to alleviate the need to develop unique infrastructure solutions.

Ten Requirements Gathering Techniques

2009-03-15T09:08:00.000-07:00

1. Brainstorming - to get as many ideas as possible, generally used to identify solutions to problems.

2. Document Analysis - for creation of AS-IS process documents, driving gap analysis for migration projects, reviewing the requirements the drove the creation of existing system and use it for validating requirements completeness.

3. Focus Group - gather representatives of users / customers to get product feedback. The feedback can be needs / opportunities / problems to identify requirements. There is danger in "following the crowd" with this technique.

4. Interface Analysis - Interfaces for a software product can be human or machine. Interface analysis - reviewing the touch points with other external systems - is important to make sure we don’t overlook requirements that aren’t immediately visible to users.

5. Interviews of stakeholders and users are critical to creating the great software. Recognizing the perspective of the interviewees to properly weigh and address their inputs. Listen carefully to get more value out of the interview.

6. Observation - By observing users, an analyst can identify a process flow, awkward steps, pain points and opportunities for improvement. Observation can be passive or active (asking questions while observing). Passive observation is better for getting feedback on a prototype (to refine requirements), where active observation is more effective at getting an understanding of an existing business process.

7. Prototyping - Often, when people can not articulate a particular need in the abstract, they can quickly assess if a design approach would address the need. Prototypes are most efficiently done with quick sketches of interfaces and storyboards.

8. Requirements Workshop - One way to conducting effective workshop is with creation of domain-model artifacts (like static diagrams, activity diagrams). A workshop will be more effective with two analysts than with one, where a facilitator and a scribe work together.

9. Reverse Engineering - When a migration project does not have access to sufficient documentation of the existing system, reverse engineering will identify what the system does. It will not identify what the system should do, and will not identify when the system does the wrong thing.

10. Survey - Well designed survey would provide qualitative guidance for characterizing the market. However, it should not be used for prioritization of features or requirements.

Scrum

2009-03-15T01:23:00.000-07:00

1. Flow

1.1 Start of iteration: Reviews and select shippable functionality to implement

1.2 Rest of iteration: Implement the selected functionality

1.3 End of iteration: presents the increment of functionality for stakeholder to inspect

2. Roles

2.1 Product Owner: achieves initial and ongoing funding for the project by creating the project’s initial overall requirements, return on investment (ROI) objectives, and release plans. The list of requirements is called the Product Backlog.

2.2 Team: The Team is responsible for developing functionality. Teams are self-managing, self-organizing, and cross-functional, and they are responsible for figuring out how to turn Product Backlog into an increment of functionality within an iteration and managing their own work to do so.

2.3 The ScrumMaster: The ScrumMaster is responsible for the Scrum process, for teaching Scrum to everyone involved in the project, for implementing Scrum so that it fits within an organization’s culture and still delivers the expected benefits, and for ensuring that everyone follows Scrum rules and practices.

Extreme Programming Rules

2009-03-15T00:41:00.000-07:00

1. Planning

1.1 User stories are written.
1.2 Release planning creates the schedule.
1.3 Make frequent small releases.
1.4 The Project Velocity is measured.
1.5 The project is divided into iterations.
1.6 Iteration planning starts each iteration.
1.7 Move people around.
1.8 A stand-up meeting starts each day.
1.9 Fix XP when it breaks.

2. Designing

2.1 Simplicity.
2.2 Choose a system metaphor.
2.3 Use CRC cards for design sessions.
2.4 Create spike solutions to reduce risk.
2.5 No functionality is added early.
2.6 Refactor whenever and wherever possible.

3. Coding

3.1 The customer is always available.
3.2 Code must be written to agreed standards.
3.3 Code the unit test first.
3.4 All production code is pair programmed.
3.5 Only one pair integrates code at a time.
3.6 Integrate often.
3.7 Use collective code ownership.
3.8 Leave optimization till last.
3.9 No overtime.

4. Testing

4.1 All code must have unit tests.
4.2 All code must pass all unit tests before it can be released.
4.3 When a bug is found tests are created.
4.4 Acceptance tests are run often and the score is published.

Principles behind the Agile Manifesto

2009-03-15T00:37:00.000-07:00

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Changing Software Requirements

2009-03-14T05:27:00.000-07:00

Craig offers his insight into why software requirements keep changing in his blog at http://www.softwareprojects.org:

Clients jump into their solution work before they properly understand their problem
In multi-stakeholder environments (i.e. large organizations) there is rarely one clear voice singing the requirements tune,
The people you put into project management and requirements management roles don't have the right skills and knowledge
The external market conditions are changing fast and it's just hard to get the product lined up with the market

Here's the solutions to first three problems (the fourth is rather impossible):

Identify the problems that the solution is solving, insist on details of the requirements and walk through the requirements document with all the stakeholders involved
Identify the most influential groups of stakeholders and involved them in requirements gathering as well as approval.
Get the right people in the project team, and if that is not possible, send them for proper training.

Managing Software Requirements

2009-03-13T23:20:00.000-07:00

1. Plan in advance for Software Requirements Management.

2. Involve Project Manager, Development Team, All Stakeholders, Client, End Users and Testing Team in requirements gathering.

3. Convince client that they need to spend time in this area as they may:
- not be capable of explaining what they need
- not have the time to meet you
- not look through your draft
- thinks they know better and give you the wrong ideas
- approve your specifications without looking at them

4. Hold long, boring meeting, and then "translate" their needs for the programmers and developers. If customers or end-users are not available, despite your best efforts, you can use "surrogates" to simulate the actual users.

5. Remain in close contact with Client for the duration of the entire process - their needs may change or they may find out something they forgot to tell you in the beginning. Inform them that you are always available to meet them and look at all options again.

6. Understand that software requirements management process ends only when your system is fully implemented, and the client is satisfied by it.

7. You should be able to trace your requirements all the time. If the requirements does not meet the projects objectives, it could be that the requirements are not captured properly, or that the project objectives is not well defined.

8. Tracing requirements also involves additional tests, performed from time to time, to insure that the process runs smoothly and errors are identified and corrected early on.

9. When a certain design is implemented for a certain requirements, make a note about the effects and the alternatives.

10. The first level consists of the specific business requirements - business background and market needs, objectives, dependencies, scope and constraints. They should never be self implied and are to be discussed in detail and captured in "Vision and Scope" documents.

11. Clients are not always very cooperative when you start discussing requirements, and it is your job to convince them.

12. Don't take for granted everything they say, insist on every single detail, and insist on talking directly to the final users of the program, or on getting information from them in one way or another. In the end, if something goes wrong, it will be your fault, since you can't blame the client.

13. Users will use all types of meaningless words, such the "the best", "the easiest", "user-friendly", "fully compatible with", and so on. It's your job to turn these into clear, measurable and traceable requirements.

14. Besides user requirements, you need to consider other external, non-functional requirements, which are not related to your client.

15. It is vital to prioritize the requirements - be realistic, some things may not be ready in time, others may not even be possible. You may categorise them into "absolutely necessary", "necessary - but can be implemented later on", "really useful to have - but can be skipped if deadline is tight".

16. If you think that the client asked for an unnecessary requirements, charge them for it if possible. Usually, when faced with the cost/usefulness ration, many people change their mind or review the situation more carefully.

17. When something changes, make sure everybody is aware it, don't just inform the developer directly about what has changed. The entire team should have a strict set of rules, and all the changes should be written down for every stage affected.

18. For every requirement document you write, make sure you also record, right on top, which version it is and when it was written/modified. Organized, efficient communication is vital.

19. For complex projects, it may be a good idea to organize a control board to approve or reject changes at regular intervals, and to make sure everybody is informed about the change and its status.

20. When formulating a requirement statement, you have to think of several elements: the actor (or the owner), the action performed, the target (or, again, the owner, as the case may be), the object, the localization and the constraints that apply. A statement may not contain all of these elements, but, if it refers to them, make sure they are specified.

21. Check to see that you didn't include two different requirements in the same sentence - this is a sure way to make the developers ignore one of them.

22. When writing in the natural language, use the words as precisely as possible. he IEEE standards have pretty clear definitions for words that you are sure to use, such as failure, error, fault - make sure you stick to those definitions.

23. Give as many examples and create as many scenarios as possible. You can test your work, particularly when you're new at this, by asking several people to read your requirements and to tell you what they've understood and how they see the possible solutions. Ask people from several departments, just to make sure that they all understand the same.

24. It's vital that your requirements can be tested and measures, otherwise they are simply useless.

25. When you have the full set of requirements, make sure it is complete, at least from the point of view of the current stage of the project. Now, check them one by one and see that they don't contradict each other.

26. Remember that the requirements have to make sense as a whole, as well as each taken individually. Also, all of them and each one separately have to be measurable and verifiable.

Motivating your team

2009-03-13T22:04:00.000-07:00

1. Start with yourself. If you are motivated, you can be a role model for the team.

2. Share information and give the team a sense of ownership - it is their project.

3. Take your problems to them to ask them for solution.

4. Keep your work environment as informal as possible. People usually work better without the boss breathing down their neck.

5. Arrange for special celebrations upon reaching the milestones on time.

6. Always appreciate your team members, saying ‘thank you’ can make people strive harder for appreciation.

7. During evaluation do not try to pin the blame on anyone as it creates an environment of distrust - either the team succeed, or fails. Not individual.

8. Provide feedback in a positive manner; give them what was done right, mention the shortcomings and how the team can do better.

9. Take individual team members out to lunch, discuss trivial things as well as work related matters and just let them enjoy the time.

10. Listen to your team members talk; give them your ear from time to time and really listen. This should be a ritual every few days to get their perspectives.

11. When a team member comes to you with a problem be positive in your analysis, try to find a definite solution and back him to work it out,

12. Always support your team, give them confidence and give them opportunities to fulfill your confidence.

13. Not everyone can handle every job. Pick the right person for the right job.

14. Eat together. You can have team lunches where someone gives a work related presentation.

15. Allow your team to try out their ideas.

16. What do people work best for? It could be money, emotional or personal attachments. Find out and instill a sense of ownership in the team. .

17. Give them something fun to look forward to. That can be some time off at a gathering or pot luck party.

18. When someone does well, be generous in your praise. Be honest and sincere though.

19. Give shy member a chance to present their ideas. Listen carefully and evaluate ideas on merit, make sure not to discourage anyone though;

20. Clarify all points to avoid misunderstanding.

21. Spot the motivators within your team; there are individuals that put a spark in the atmosphere, they are active and they compel others to show the same energy without ever saying it.

22. Brainstorming sessions produce some great ideas and when they are one on one they show your team members they are considered important.

23. Divide the project into parts where you can give individuals smaller achievable goals.

24. Achievement of organizational goals should lead to benefits. These can be monetary benefits as well as packages that provide the team members, e.g. medical cover or something similarly advantageous.

25. Last but not the least, keep Maslow's Hierarchy of needs in mind; not every individual has the same motivational needs.