Agile Reporting From Waterfalls

A diagram on agile methodology concept

Quite a few customers are jumping on the ‘Agile’ bandwagon these days, choosing an Agile methodology for specific projects, or for repetitive releases of their product. A challenge they are facing is how to manage and report Agile projects when the processes and templates provided by their PMO have been developed for Waterfall projects. And of course, that content is what their stakeholders are used to receiving and discussing.

In Waterfall projects there often are Status Reports which list the tasks in the current work packages and their status. The tasks come from an agreed, project-wide Work Breakdown Structure.

In an Agile Scrum, there is no previously broken down, far-reaching Work Breakdown Structure. The team works from a ‘Product Backlog’, or prioritized list of functionality, which they have agreed with the product owner. They then commit to deliver a certain portion of functionality during a 30-day Sprint. Since the team organizes itself on how to deliver this functionality, and checkpoints daily on their progress and problems, the content of the work is very fluid. They cannot commit in advance to finishing this or that task in this or that timeframe. All they can commit is to deliver finished, working functions by the end of the 30 days. At the end of the Sprint, a “Sprint Review” takes place. So how could one issue weekly status reports, when Scrum offers no Work Breakdown Structure? Just the daily checkpoints and the review of the Scrum at the end of the 30 days?

I am sure there are a variety of creative workarounds Project Managers (ie, Scrum Masters) are using. One of the more successful approaches I have seen entails using the ‘Product Backlog’ as the basis for a status report. The Scrum Master can list the requirements or functionality in the Product Backlog as if they were work packages. Then, they discuss how close to completion these various functionality items are. Sometimes there will be a requirement in the Product Backlog which is not easy to visualize as a work item, such as “User Friendly Interface”. In this case, verbs can be added to give the stakeholders an idea of what the project team is doing, such as “Test Interface with 4 different types of users”. This ‘hybrid reporting’ will then allow the Scrum Master to perform another very important responsibility: protect their project team from distractions and interruptions during the Sprint.

The Pareto Thing

Pareto principle illustration

The past few weeks have been quite busy helping a client prepare for an arbitration between a project contractor and the management of a troubled project. An arbitration is less severe than a lawsuit, in that the parties in disagreement choose an ‘arbitrator’ who is well qualified in the industry, to decide who is right about which claim. They then agree to abide by that decision. Much cheaper than a lawsuit, apparently.

We are reviewing the contract, deliverables, deadlines etc. on a given section of the work, when I notice the monetary amount in that section does not seem very large. Diplomatically, I suggest we do a “Pareto Analysis”, and prioritize the preparation of the larger items.

Pareto Analysis (also known as “the 80/20 rule”), refers to the analysis of the Italian economist Vilfredo Pareto, where he observed that 80% of land in Italy was owned by 20% of the population. More recently, it has been applied to many more uses: what 20% of the effort would contribute to 80% of the improvement; which 20% of customers bring 80% of your business.

“Oh yes” said my customer, “let’s do the Pareto thing”. So instead of a small work item, we analyze and document an item which -by itself- is more than half of the total amount in dispute.

Pareto analysis is one of the first tools the project manager should reach for, suggesting to us which 20% (ie, small amount) , if addressed, would bring us the 80% benefit (ie, large amount). It can help us prioritize change requests. It can help us organize the resolution of problem log items. If funding has shrunk, it suggests which work to keep in scope; which to de-scope.

Even in Agile Scrums, Pareto Analysis can bring clarity to the product owner about which high priority work to deploy in the next Sprint. It can be applied to large items -such as which budgets to analyze first- and to small items -which phone calls to return first-. So do use it extensively.

As to my customer’s arbitration: they lost 2 items and the contractor won 2 items. The contractor’s items were about 25% of the amount in dispute, my customer’s items were 75% of the amount. The contractor just did not present a very compelling argument. He must have run out of time. For my customer, the Pareto thing paid off handsomely.

‘Agile’ or ‘Waterfall’ ?

agile methodology

A few days ago, before the start of a meeting, a couple of developers where discussing ‘Agile’ project management versus the more traditional ‘Waterfall’ project planning.

A ‘Waterfall’ approach, you may recall, is the type of project that flows sequentially from stage to stage, much like a waterfall. It came from, and was heavily influenced by, the Manufacturing industry. The names of the stages vary, but roughly include: Proof-of-concept -> Initiation -> Requirements -> Design -> Implementation -> Testing -> Go Live (& Turn over to Operations). Although it does allow for change requests, it is definitely quite structured in progressing from stage to stage.

The ‘Agile’ approach on the other hand, came into being for software development, which often is non-linear, reactive, and has as an objective to deploy useful items very quickly. In an Agile project, the “product owner” decides which are the highest priority items to be included in the next iteration. The entire big picture, or thorough system requirements, may not be fully known . What is known, is that these high-priority features must be developed now. So the team delivers these items, hopefully with great quality control, and the next iteration is prepared after that.

‘Waterfall man’ was extolling the virtues of arriving at consensus on project scope from the beginning; agreeing timeline and costs; carefully tracking progress, then introducing change requests whose merit had been approved by all. ‘Agile man’, on the other hand, was calling him a dreamer, saying that such a staid and rigid approach was completely last century. That 21st Century projects need to deliver much more quickly than stodgy Waterfall projects could ever manage to.

I’ll have to say that both of these guys were making really valid points. If I am able, as a project manager, to lead stakeholders to consensus on features, priorities, total cost, total timeline, etc, doesn’t that yield a better price/performance project than deploying it ‘piecemeal’? If I have a good, decisive Executive Sponsor, who is able to map the project’s scope to company strategy, won’t that lead me to a successful and relevant implementation?

On the other hand, if my project deploys features before my competition does, and I get more customers as a result of small but important changes, doesn’t that trump the time required for sequential project planning?

Surely there is room for both methods then. If I can lead stakeholders to agree on crisp, prioritized scope items I should use the orderly “Waterfall”; I should deploy a project with the most requirements for the least effort. But if all we know is that there are critical features that must be deployed in the next 3 weeks −or something terrible will happen− then I should organize an Agile “Scrum”. It might be another case of that old saying: the right tool for the right job

Program Or Project ?

When an organization has the function of deploying multiple initiatives, the question arises: should these be managed as projects? Or should program management enter the picture?

If there is an obvious way in which the projects are related, we may opt for program management straightaway. For example: if our organization deploys a few projects per customer, the group containing the initiatives for customer ‘X’ could be deployed as a program. Or if we perform projects containing technologies ‘A’ and ‘B’, the projects requiring product ‘A’ could be treated as a program, separate from the program containing technology ‘B’.

Sometimes it is not obvious, yet we would obtain better results if a set of projects were treated as a program. Examples:

* Projects containing the same issue (say, travel to Iceland)

* Projects containing the same pre-requisite (say, a specific expert’s approval)

* Projects expected to have a similar result (say, energy-saving)

So we could say that to make a good determination, we must analyze the big picture represented by our portfolio of projects in addition to obvious categories, to see if they would benefit from coordinated management of some aspect(s).

Once the determination is made, there are steps we can take to minimize the cost or improve the benefits of the program. Here are a couple:

Set Up Good Program Governance

Projects are ‘managed’; programs are ‘governed’. Setting up program governance means establishing procedures and structure that will help the projects in this program achieve the best possible results. For example, establishing a common risk management framework to be used on all ‘energy-saving’ projects. Or specifying procedures to be followed for all projects belonging to the ‘government’ sector.

Establish High-Level Program Plan

After governance items have been agreed, a high-level plan for this set of projects with a common theme can be drafted. In planning, program management starts to look similar to project management. A series of processes will be performed in order to yield a robust plan for the program. There are myriad articles and publications on good program management, so let us just mention just a couple that may sound familiar if you have studied project management: managing the Program Scope and Program Schedule.

A) Program Scope Management – In this exercise we determine the scope of the particular program (for example, those energy saving projects). We agree what is included; how to resource; expected benefits from this program. We also interface with other departments in the organization -such as marketing- to leverage the program to even greater advantage. Ultimately, planning the program scope will yield a Program Work Breakdown Structure, or PWBS. This PWBS is very useful, because it even mentions deliverables that should be generated by all projects belonging to the program.

B) Program Schedule Management – The schedule of the program is the timetable when the different program work tasks will be executed. It describes not just when certain program components will be deployed, but for the projects belonging to this program, the timing when certain deliverables should be produced.

Hopefully this has been a useful introduction which will provide some food for thought on projects versus programs. In future blog articles we will look at other helpful techniques in the management of a group of projects, which should help you (pun alert!) to stay with the program.

—————————

For more resources, see the Library topic Project Management.

—————————

PRINCE2: The Most Popular PM Exam In The World – Guest Post by Simon Buehring

Why is PRINCE2® is the most popular project management exam in the world?

By Simon Buehring

During September 2012, APMG-International, the PRINCE2 accreditation body announced that more than 1 million PRINCE2 project management examinations have now been sat. This is more than any other project management method. In this article I want to explore the reasons why PRINCE2 has become so popular.

Firstly, let me explain what PRINCE2 is. PRINCE2 stands for PRojects IN Controlled Environments. It began life as a UK government framework for managing I.T. projects in the 1980’s and was known as PRINCE, but was redeveloped as PRINCE2 in 1996 when it became a generic project management framework. Since then the manual has been revised several times and is widely regarded as embodying modern best practices in project management.

Since 1996 more than 1 million examinations have been sat, approximately two thirds of which have been at the lower Foundation level and the remaining one third at the higher Practitioner level. Both examinations are multiple choice formats with candidates being tested for their knowledge of the framework at Foundation level, and their ability to apply this knowledge at Practitioner level.

Although the bulk of exams have been taken in the UK, the examination is becoming more popular in other regions, particularly in Europe. As the chart shows, for the period 2005-11, more than half of all exams were taken in the UK with a further quarter taken in the rest of Europe. Australasia was the next biggest region and North America the lowest region with less than 1% of all exams taken during the same period. So, why is the qualification so popular in the UK and Europe but less so in the US? I think the answer lies primarily in the labour market conditions of each region which is driving the requirement for job candidates to have project management qualifications.

PRINCE2, being based upon modern best practices in project management, has proven to be the project management method of choice for increasing numbers of organizations. Not only have the United Nations and NATO adopted PRINCE2, but increasing numbers of private sector companies have too. When world class businesses such as Rolls Royce, Visa and Vodafone adopt PRINCE2, it’s time to sit up and take notice. Driven by the need to remain competitive, more and more organizations are undergoing change, whether to business operations or through the development of new products. I think this is driving organizations to become more project-ized, and hence the need for more project managers and effective and proven project management methods.

Based in the UK, I am always struck by how many students are taking a PRINCE2 course and exams because they see PRINCE2 qualifications as important ingredients on their resumes. Employers are seeking increasing numbers of project managers and require the qualifications to match. The situation in North America is quite different in that most employers are likely to want candidates with the PMI’s PMP qualification rather than PRINCE2. This simply reflects the fact that the PMI’s PMP qualification and the PMBOK® GUIDE is more widely known and understood in North America, whereas PRINCE2 is better known and understood in the UK and Europe.

So, are PRINCE2 and the PMBOK simply two different choices in how to manage projects? Is the choice of which one to use simply a matter of personal preference? Well, I think that the PMBOK and PRINCE2 bring slightly different but complimentary elements and project managers can benefit from applying both. The PMBOK explains the knowledge required by a project manager to perform core project management practices such as time and cost management. However, it does not cover the responsibilities of other members of the project management team such as project sponsor, users, suppliers and team managers. Nor does it cover other important aspects such as project governance. Students who attend PMP training are often left wondering afterwards how they should actually start the project.

PRINCE2 on the other hand is a process based approach which clearly describes what needs to be done, by whom and when during a project. It doesn’t concern itself with the knowledge areas of the PMBOK and leaves it up to the project manager to choose appropriate techniques. PRINCE2 is a process framework for planning, managing and controlling any shape or size of project in a systematic manner. Having used PRINCE2 on many projects, I find its principles-based approach is extremely flexible in the way it can be implemented. Its focus on ‘management by exception’ can also save senior management time because there is no need for regular progress meetings. It is these benefits of PRINCE2 and the ease with which it can be used which I think is encouraging its adoption by more and more organizations.

So, if you’ve already studied and used the PMBOK and gained your PMP qualification, is it time to study and take a PRINCE2 exam? Yes. By attending PRINCE2 training it will help you understand how your detailed knowledge of the PMBOK can be complemented by the process clarity and project control elements of PRINCE2 and so help you deliver your project more effectively. Now, will you plan to take your PRINCE2 exam?

—————————

For more resources, see the Library topic Project Management.

—————————

Simon Buehring is based in the UK and is the founder and Managing Director of Knowledge Train which is a PRINCE2 accredited training company.

PRINCE2® is a registered trademark of the Cabinet Office. PMBOK® GUIDE, PMI and PMP are registered trade and service marks of The Project Management Institute, Inc.

Successful Strategies for Global Projects

No doubt installations in other geographies come with their own inherent set of challenges. Currency fluctuations; centralized versus local procurement; languages; time zones. And those are even before considering difficulties due to the particular technology being deployed, or the source of spare parts, or infrastructure in the country.

This discussion aims to introduce a technique which can help you increase the acceptance of your initiative in other geographies, as well as resolve any disagreements quickly and with much improved team spirit.

No, it is not the traditional Project Management methodology: I will not start extolling here the virtues of the “Project Charter”. The magic ingredient in international projects, as I have discovered throughout 18 years of successfully deploying such, is treating our colleagues from other countries in a manner which puts them at ease.

Notice that this recommendation goes well past the tired old adage: “Treat those from other countries with sensitivity”. That much is obvious, and we would certainly try to conduct ourselves thus. The recommendation is to approach colleagues from another geography with a demeanor they would find in their own country. In other words, if you are dealing with Brazilians, try to ‘act Brazilian’ as you collaborate with them; if you are working with a Finn, try to ‘act Finnish’.

So how do we develop a good picture of what ‘acting Australian’ or ‘acting Japanese’ might entail? Fortunately, there’s excellent research on intercultural cooperation we can consult. Fons Trompenaars’ Riding the Waves of Culture, or Nancy Adler’s International Dimensions of Organizational Behavior are some of the best books on the intercultural topic.

My personal favourite in the “intercultural” arena, as relevant today as when its first edition was published in the UK in 1991, is Cultures and Organizations: Software of the Mind by Dr. Geert Hofstede.

The ground-breaking contribution of Dr. Hofstede’s research is that, through thousands of surveys of IBM professionals in dozens of countries, he is able to arrive at a numerical value for certain elements or “dimensions” which make up Culture. So for example, we learn that Malaysia, on average, has the highest score (104) for “Power Distance”, meaning that as a group they are quite comfortable accepting power inequalities in society. At the other extreme, Great Britain and Canada have low scores (35 and 39 respectively), which translate into a “limited dependence of subordinates on their bosses”. In other words, British and Canadian employees (as a group) are not afraid to approach their bosses or disagree with them.

Another useful discussion centers around the topic of “collectivistic” cultures (where the interest of the group prevails over the interest of the individual) compared to “individualistic” cultures (in which the interests of the individual prevail). It comes as no surprise that the country with the highest individualism score is the USA (91), closely followed by Australia (90). At the other extreme, the countries with the lowest individualism scores are Ecuador (8) and Guatemala (6).

Personally, I have leveraged his findings to arrive at the following communication paradigms, in order to make my counterparts in other geographies more at ease as we negotiate and coordinate project milestones. It has proven a huge advantage, as the largest difficulties in technology projects are not about the technology. They are about people.

With colleagues from Latin America (Venezuela, Panama, Mexico, Brazil, Colombia) and certain Asian countries (Pakistan, Thailand, Malaysia, Indonesia) with large acceptance of power,
• Stress clear definitions: what constitutes in-scope vs. out-of-scope
• Stress the benefit to the whole project/company
• Stress checkpoints for scope verification
• Lively exchange, having fun, yet sticking to the rules

With collegaues from Northern/Western Europe/Australia/New Zealand, which exhibit large individualism,
• Have all the facts, be decisive
• Recognize the contribution of these colleagues
• Relaxed approach, not stressing hierarchy
• Sell/negotiate work deliverables
• Stress value of the project to their particular unit

How would you know a country’s “Individualism (IDV)” or “Power Distance” (PDI) scores? The best source would be Dr. Hofstede’s book. Alternatively, ITIM International has kindly published the scores in the website http://www.geert-hofstede.com/

I hope you find these recommendations useful and that they make you successful in your next international project.

—————————

For more resources, see the Library topic Project Management.

—————————

‘Fusion’ Project Management

Fusion. It’s all the rage in culinary circles, right? Restaurants that prepare great dishes from pan-Asian countries, or pan-Latin American countries, or even European and Asian combinations. All with great, flavorful results.

We can bring a similar mindset to the management of our projects. By combining different methods and strategies we can craft our own ‘fusion’ project management structure, so it includes the best of different schools of thought, yet fits the project well. Although my basic methodology, as those who follow this blog know, relies on the PMBOK® from the Project Management Institute , I often supplement it with some of the following concepts:

From PRINCE2:
In PRINCE2, the project manager takes input from a ‘Project Board’ on important decisions. This Board is made up of representatives from three groups: a Customer, a Senior User, and a Senior Supplier. The combination of skills balance the decision-making very well, so I try to incorporate such a Project Board into my projects whenever possible. Say, to review the Risk Log once per month. More detail on PRINCE2 can be found at ‘prince-officialsite.com’ .

From Agile:
Certain projects see a great deal of change and re-prioritizing. Maybe a technology is new; maybe management wants to react to the market’s shifting requirements quickly. Whatever the underlying reason, when the mandate of the project is to be reactive, the team needs an Agile project management framework. SCRUM is such a framework.

It is based on a focused effort, called a “Sprint” towards fixed goals. What is important is that the scope delivered in each Sprint provide the highest possible market value. By the next “Sprint”, the scope of the project will most likely have changed again. So in some projects, we will have milestone-to-milestone scope definition, knowing full well that the Scope Document will have to be revised (again!) after the next milestone is reached. For more information on SCRUM, you can visit ‘scrumalliance.org’.

From “The Lazy Project Manager”:
Peter Taylor advocates in his book, The Lazy Project Manager, that in running our projects we should exercise “productive laziness”. This means that we concentrate our efforts where they are really going to make a difference to project goals, rather than just running around looking for things to do, sometimes of dubious importance. It also means artfully saying ‘No’ more often than we are probably accustomed to.

There is more about Peter’s methods at ‘thelazyprojectmanager.com’ . I could give more examples, but in the spirit of The Lazy PM, I think I will go for a coffee now. Thanks for reading.

—————————

For more resources, see the Library topic Project Management.

—————————

How to Manage Your Time as a Project Manager, by Andy Trainer

Guest Post by Andy Trainer, from Silicon Beach Training

Project managers need a great deal of technical knowledge and project experience in order to do their job. Companies looking for an effective project manager will therefore ask prospective candidates for evidence of training and of managing successful projects.

What isn’t always appreciated is the skill in time management needed by project managers. Anyone with ‘manager’ in their title will have conflicting and varying demands on their time – but a project manager will have this more than most. The levels of control required by most PM frameworks, plus the need to manage a team whilst always reporting back to the client/executive, means project managers have just that little bit more on their plates.

The purpose of implementing project management techniques is to avoid wasting time, money and resources. A project manager who is not great at time management will eventually find that the effectiveness of the project suffers as a result. With that in mind, here are our tips on how to manage your time as a project manager:

STICK TO A FRAMEWORK

There are numerous different approaches to project management, and it’s important that everyone involved is working to the same guidelines. Without this consistency, you may find that different members of the team follow different processes – and wasted time will follow. Choose your project team with this in mind, and fill any training needs before the project begins.

FOCUS ON THE PLAN

Inherent to any formal project is the project plan. The two extremes of project managers – those who are inexperienced and those who are blasé from managing projects for a long time – have a tendency to forget the importance of the project plan once it has been initiated. Always stay proactive – meet any challenges by returning to and revising the original project plan.

BE A GOOD PEOPLE MANAGER

Another sign of inexperience – or too much experience – is of focusing on the task as opposed to the people on the team. Micro-managing because you know how to do the work quickly is not a way of saving time, no matter how tempting it may be. Your role as a project manager is to manage and guide – not to do the job yourself.

KEEP YOUR MEETINGS ON-TOPIC AND PRODUCTIVE

Overly long meetings are so commonplace that it almost seems that people have accepted this nature and stopped trying to make them more efficient. Have a look at these guidelines for conductive effective meetings.

TAKE TIME MANAGEMENT SERIOUSLY

The number one sign of someone who is failing at time management is someone who claims that time spent planning is a waste of precious time. Those who say they don’t have time to take a step back to prioritise time management over doing are doomed to failure. Whilst an office manager or site manager may have their time management skills scrutinised, you’re not likely to have this as a project manager – there are many other aspects of the project that are being valued instead.

If you feel that you have too many demands on your time, take a step back and plan – in what ever way works best for you. Whether this is in the form or to-do lists or otherwise, the main thing is that you make time management a priority.

—————————

For more resources, see the Library topic Project Management.

—————————

Silicon Beach Training Brighton-based training provider, offering both Time Management and PRINCE2 Foundation training.

So Are We Doing This?

I was recently teaching a course where the discussion turned to project resourcing, and the problem of people being stretched more thinly than ever. I suggested to the student that maybe her company’s mechanism for “project selection” needed to be revisited with her management, so that the number of projects could be decreased until the excessive workload was completed. “There would be no point” she said, “my manager says ‘yes’ to everything”. A few other students nodded in sad agreement, hinting that they faced a similar behavior.

It was very unfortunate because the responsibility of a company’s management is, precisely, to prioritize in the face of constrained resources. It is not to take the easy way out, “say ‘yes’ to everything”, and demand that teams work under stressful conditions. Although it may look like such a manager is being cooperative, this is not the case. The result will be disappointed customers, or overworked employees who will become ill or leave the business. In other words, ‘saying yes to everything’, while easy, is not sustainable. It also doesn’t merit the higher salary that managers command for supposedly making thoughtful and informed decisions about organizational resources.

The PMBOK® methodology from the Project Management Institute is very clear on the topic of project selection. Its best-of-breed steps recommend starting, not by Planning a project, but with a proper Initiation of the project. What happens during Initiation? The feasibility of performing the project, in light of other proposals/ requirements/ constraints is studied and deliberately approved. This exercise can only be effective if the entire portfolio of possible projects is considered and prioritized, to make sure that only the more worthy projects are the ones formally selected. Formal selection means then, being willing to invest enough resources to deploy the effort successfully.

Can this mix of ‘selected’ projects change? Yes, certainly. A few months after the entire portfolio is prioritized, new potential projects can be discovered that merit ‘selection’. In this case, some previously selected projects may have to move to the back-burner, or another source of funding identified to deliver the new mix of projects.

We could think of the whole exercise as a household’s budget. It is finite and constrained, so which expenses will be a part of the budget need to be prioritized and deliberately selected. If suddenly it becomes critical to have little Timmy take guitar lessons, then something else will have to fall out of that budget. And it becomes obvious that the household can’t “just say yes to everything”.

—————————

For more resources, see the Library topic Project Management.

—————————

5 Leadership Skills for Project Managers

Guest post from Claudia Vandermilt:

As a project manager, your teams rely on your leadership skills to guide and encourage productivity and project success. When provided with quality leadership, team members often respond positively; they build stronger relationships and rise to project challenges brought forth by their leader. Arm yourself with these five critical leadership skills to help propel a winning team:

1. Provide Structure

From the very beginning of a project, you must have a structured outline of your vision for the team. Each person should be clear on your mission, the timing and how you plan on achieving project success.

Create a project-specific document, in addition to the standard documents outlining roles and responsibilities. In the document, include team biographies, each person’s role and a personal anecdote; knowing something personal about each other, such as a team member’s home town or college alma mater, provides an opportunity for group bonding.

Additionally, each team member should be tracked and rated; follow their performance regarding specific assignments and their overall-project contribution.

 

2. Communicate Clearly

Communication is key and can make or break the success of your project. Clear, consistent communication can be a challenge; the days of only communicating via phone and email are long gone.

Technological advances such as Facebook, Twitter, smartphones, video conferencing and other social networking tools allow for team members all over the world to maintain real-time knowledge of project components. It is up to you to leverage these technologies in the most efficient way, and to make sure that the communication channels you use are locally available and culturally accepted.

3. Lead by Example

All project managers must foster a positive environment. In order for project success, all members must feel confident in executing their responsibilities; you must project a winning attitude and make decisions based on the best interest of the team. Make yourself readily available to team members, and always deliver project components on time (or early). Lead your team by example, and they will respond accordingly.

 

4. Encourage Trust

Trust between team members is vital to project success. The most important factor in building trust is based on completion of commitments. Whether commitments are based on planned tasks or verbal promises, team members must be encouraged to follow through in order to gain trust within the group dynamic. Team members should respond in a timely fashion to all requests, and offer to assist others when needed.

5. Motivate

All teams need a strong leader to motivate them through a project, regardless of the size or length of the project. It is your job to find the best ways to properly motivate your team. Recognizing team members for going above and beyond the scope of their responsibilities creates a cyclical response; your positive reinforcement motivates their work ethic. Make sure to verbally thank your staff, and consider rewards such as a bonus, vacation time, team dinners or gift cards. Keep rewards simple, and make sure all team members who strive for success are recognized.

With these five essential leadership steps, you’ll increase efficiency and team performance, and encourage early deliverables leading to successful project completion. Engaging and connecting with your team helps facilitate these skills and builds stronger, more positive relationships.

—————————

For more resources, see the Library topic Project Management.

—————————————————————————————————————————–

Claudia Vandermilt works with Villanova University as a copywriter on professional education, online certificate programs and career training. Villanova offers master certificates in project management, human resources, six sigma and other prominent fields.