Leadership: On Developing Teams - Are you alone on the Ice?

Alone on the ice, surrounded by mountains and snow in the darkness. The faintest sliver of moon is barely brighter than the thousands of stars overhead. A cold, clear sky on a windless night, -16C/3F outside. I am dressed warmly but a small shiver escapes me.


Feeling very, very small indeed.


I am standing in the middle of Lightning Lake, British Columbia, Canada. The light of the stars is bright enough for me to easily see the contrast of light and dark - brighter, actually than I thought it would be. An igloo stands a ways back, off to my left. 

I check my watch. Time to go in.

I turn and walk in silence, a hundred paces back the way I came - where I join the rest of the scout troop I am leading. They have retraced their own steps back to the circle.


Technically I was not really alone - however with everyone separated and facing away from each other, looking only at the sky, the lake and the mountains, it was very easy to imagine you were indeed alone out there.  


In absolute stillness.

We waited for the last few to join the circle and then we quietly shared observations of the experience. Most felt small, insignificant, alone in the vastness - but also not alone, either. They were not talking about the other members of the troop hundreds of feet from them - they were feeling small, but also part of their surroundings.  Maybe the start of a sense of belonging to nature, and a few did not feel as cold standing there as they did on the walk out onto the lake.

The interesting part of the whole exercise was that from being and feeling quite alone out on the ice, we walked back to camp with a deeper connection from the shared experience of being alone in the universe - together. And I am quite sure that each of them will remember the experience as long as they live.
...

There is no one prescribed way to build a team, but the common thread in all successful methods is in doing things together. Whether you are leading and developing the youth who will be the leaders of tomorrow, or working with already-grown-ups, the principle is the same.

Teams grow and bond (and sometimes break apart) through challenges and the shared experience of building or accomplishing things - together.

Developing a Team

I was a Scout Leader for almost 11 years. I started as a youth member as a Cub and then continued on through Scouts and Venturers to Rovers, when each of us assisted other groups as adult leaders. My first few years as a leader with the Scout troop were learning years; I made a lot of mistakes and learned from them. The troop was a pretty steady size through the years as youth entered from Cubs and then moved on to Venturers (if they continued with it). We did the camps, skills training, all of that - and it was rewarding to see the kids learning and gaining self-confidence.

Around half-way through my years as a Scout Leader, we gained new kids and their parents as leaders, which is usually how it works. However, that year, we gained an exceptional Leader in one of the parents, who had moved with his kids up from Cubs. The leadership team flourished under his guidance; we felt supported and energized and together we were able to put on an exceptional programme that year. The following year he surprised me. He refused to be the head leader again. He insisted that I should do it - me, the youngest of them all, in my early 20's. All of the other leaders were in their thirties or more, some with other kids older than the scouts. Worst of all, they all supported his endorsement.

What were they thinking?

No Going Back

I was terrified.

What if I screwed up? What if I embarrassed myself in front of the other, much more experienced adults? Would people take me seriously? I suddenly felt a lot younger than 20-something. I felt like a kid. I wasn't ready for this!

However, there was no going back. They would not take "no" for an answer. My sentence was to be carried out, starting the first week of September that year.

Building by Stepping Back

I did not know it yet, but the other Leaders were following the adage "It's better to build a boy than mend a man." I was not a boy any more, though I suddenly felt like one in the face of this challenge. But the principle is one that I have tried to use myself on a regular basis over the years, because it works - and it is the only way that society moves forward.

You need to build up your replacements - the next generation who will take over from you, who will (in theory) in turn help raise up the generation after that.

I made a lot of mistakes that year. Far more than I had made in all the prior years as a leader. Of course any of the other leaders could have done the job, or even stepped in to clean up after me, or even taken back the reins. But they never did, even though a few times in the first few months I secretly wished they would.


The mistakes I made were not really "big" in the scale of things; nobody was ever at risk and the evenings and camps went off fairly smoothly with the leadership team working together. But to me - as my first time as the "Main Leader" (or "Skip"), every mistake seemed big to me, with all eyes watching.

I kept waiting for the shoe to drop. But it never did. The other leaders supported me, coached me, mentored me - but did not embarrass or chastise me. It was an amazing year - I learned an incredible amount, and even more in the years that followed as we worked together. I grew in confidence and ability all the while - and I also wanted to prove them right in putting their faith in me. I still made mistakes here and there in later years - but they always helped me out.




They wouldn't let me be anything other than "Skip" for several years. In time, l left the group when I finally had my own baby at home and time pressures and priorities changed.

It was a humbling first-hand lesson in "Building by Stepping Back" - seeing potential in another person, putting them into a position where they have no choice but to grow and develop - all the while encouraging them, building them up and not letting them quit.

They were, without question, all Exceptional Leaders, for which I am grateful.

Don't Give Up - And Don't Touch the Reins

When you are working with people on your team - youth, adults, it does not matter - you need to have extreme patience as they gain experience. They, as I did, will make mistakes. Probably a lot of them at first, and fewer as time goes on. Most people want to do well, to prove to themselves and others that they can do the task, and be good at it. Few people plan to be screw-ups.

In fact, if someone feels that they are continually a screw-up, it is often not their fault - the fault most likely rests soundly with their leadership. Here are some key ingredients to ensuring that your new team member can flourish in whatever role they are assigned:

• Give them the full Job Description
• Give them the Tools
• Give them time to Learn
• Encourage Questions
• Let them make Mistakes
• Support / Coach them
• Don't Step In
• Give them latitude to Grow

Give them the full Job Description
Most people will be frustrated if they are given a task without a good description of what it is they are supposed to do. If you have not clearly told them the goals or objectives, you can't expect them to deliver. Some will quit and move on, others will stay and struggle noisily or slide backward in silence. So tell them clearly what it is you want them to do from the outset.


Give them the Tools
There is nothing more frustrating than being assigned to do something, and then not be given the tools, resources or authority to do so. The "tools" will vary, but whatever it is they need to get the task done, you should provide for them. The trick is if you know at least some of the tools they will need, to have them available at the beginning - and when they recognize what else they need, be willing and able to provide those as well. This might include training, so be prepared to invest the time and expense for them to take it.


Give them time to Learn
Learning something new takes time. The time will vary from person to person based on their skills, aptitude and background - but they will take some time to ramp up before they can start performing well on the task. Of course, they can't take forever to get up to speed; if they are having trouble doing so, it might be a skills gap, or they might not be a good fit. So be reasonable in your expectations - but if they seem to be struggling, make sure they are clear on the description and have the tools available to them before you pounce.




Encourage Questions
"There are no dumb questions" is an approach that will get you better results than persecuting those who seem to ask "dumb" obvious questions. The answers may be obvious to you, but give the team members the benefit of the doubt that their questions are sincere, and they are not just mucking about. If you put down or dismiss the "dumb" questions, this will more than likely cause them to shut down and not ask the next questions - the really important ones that may make a difference to the outcome of your project.
 
Let them make Mistakes
Let them know that making a mistake is not a punishable offence. (Well, unless it is a reaaally big one, or if they intentionally screw things up, maybe). We all make mistakes as we learn and grow and try new things. But making a lot of small mistakes and learning from them early on can prevent some biggies later on. I know I have learned a lot more from my mistakes than my successes. Learning from your mistakes makes for a stronger team - and if you encourage an open, sharing environment, others in the team can learn from each other's mistakes rather than them all having to make the same mistake on their own schedule. 


If you look to some of the great inventions of history, those often came out of a "mistake" - a side effect of an experiment that did not quite work out, or "happy accidents". So encourage mistakes - it could even lead to the Next Big Idea for your company.


Support / Coach them
This one is important, and is a delicate balancing act for the leader. Early on, you will need to be around more, checking on them for progress and to see if they need anything, any clarifications on the task, tools or resources. Also make yourself available, ad-hoc or scheduled times, whichever works for each team member. However, don't smother them. The art of coaching and mentoring deserves volumes on its own, but let's sum up by saying you will benefit from knowing when you need to be there close by - and when you need to step back. As the team matures and becomes more self-motivating and more self-sustaining, you will often be best to step back further out of the works, but keep track of things and make sure they know you are available when they need you.

It also goes without saying that coaching does not equal chastising; sometimes you might want to yell at the team member for something "really stupid" that they did - but unless it is a very serious concern, try to avoid criticizing as much as you can. It takes months or years to build up a team - and seconds to destroy it. If you do need to correct a team member's behaviour or work approach, look at less confrontational ways to go about it, and start with something positive.


Don't Step In
It is very tempting to step in and "help" the team member do something they have not quite gotten the hang of yet - especially if you used to do it yourself. Resist the temptation. Let them try and work it out themselves - and if they ask for help, give them specific help and then step back. No baby ever learned to walk by having their parents do it for them.


Give them latitude to Grow
Odds are, the team member is going to approach the task in a different way than you would. Unless it would negatively affect the work result, it is usually best to let them figure out a method that works for them. They might hit a wall and have to go back to the way that it is normally accepted to do the task - but sometimes their fresh approach with new eyes will reveal a much better way of doing things. So don't stifle creativity unnecessarily - unless it does seem to be putting the deliverable at risk.  (Some people just like to figure out new ways to do things just because they can).


Note: In some countries, if you hire a contractor to do a job and then you proceed to tell them in detail HOW to do the job, you can be sued for Breach of Contract. The reason being is that you hired them, as an expert, to do a specific job. How they do it is up to them - as long as they produce the result (within safety and legal limits and regulations as applicable). They are the expert in doing that task, after all.


Not exactly the same situation when you are dealing with a team member, but you get the idea.



If you support your team members, provide them the tools and give them clear direction - they will often out-perform your expectations. They may even go on to become a High-Performing team.


If your team can accomplish that, it's a sign of good leadership. The credit does not all belong to you though - yes, the team achieved that level with your guidance. However you could just have easily prevented them from accomplishing what they had by making poor leadership decisions. So don't get cocky! There are no guarantees on what will happen with the next team.

Your High-Performing Team Gets Stale

Eventually, after your team has been working together for some time, you may reach a very high-performing level (Not all teams do). When you do, you will be able to accomplish some pretty amazing things - and the team could be a key differentiator for your company in the market.

But there is a risk with High-Performing Teams. If they are not presented with new challenges to work on, they could get stale if they are a long-standing team. If the tasks become repetitive, your team will lose interest, and lose their edge. Eventually, the team will dissolve as one after another they move on to new challenges.

This might be an inevitability - you might have a team that reached a high performing level during the project, but then the need for the team is removed. You can't keep them together on this project, so you have two choices:

• Try to get them involved in the next project together, where they will have a big head start on working together effectively, or
• Seed them throughout the organization. When you have people that have been part of a high-performing team, they will want to try to replicate what worked for them in their next team. You might end up with multiple new High-Performing teams as a result. Not all of them will pan out, but if you are able to expose more people to what it is like to be part of a High-Performing team, you have a better chance of spreading it to the reaches of your organization - and that may truly differentiate you in your market segment.

Summary

A quite different Troop walked back to camp from the center of the lake. Much more subdued and contemplative than the noisy bunch of kids that were chatting away as we walked out onto the ice earlier in the evening. In some small way they had changed that night - matured, or at least become more aware of the world around them. A small step towards leadership - you cannot lead others by only looking at yourself. Unfortunately, all too many of the activities that our children participate in these days are the exact opposite - self-absorbing video games, texting, online chats and social media that insulate them from direct personal contact with others. There is no substitute for the real thing - human interaction and learning to observe others. I look around me sometimes and wonder where the next generation of leaders will come from - and how they will manage.


That was my last year as Skip with the Scout Troop, and the last year working on a regular basis with that particular leadership team. A wonderful shared experience through all of those years - both working with the leadership team and the support they provided, and witnessing the accomplishments of the youth in the Troop as they outperformed our expectations within their smaller Patrol teams. Anyone who has low expectations of the capabilities and skills of a 10-13 year old never met any of our Scouts.


Note: The igloo was a real one - someone had carved the blocks out of the firm snow earlier in the day. We all took turns going inside it - and it definitely was warmer inside than out. The whole camping weekend was a great experience - and it stayed cold enough so that we did not have a problem with thawing and slushy snow. Nothing worse than trying to dry your gear outside when the temperature is around 0C/32F. Wet gear is not only inconvenient, but dangerous in those temperatures and below.


Good luck with your projects, and my advice today is not "Go jump in a lake" but "Go for a long walk on a lake" - just make sure it is winter, and check the ice thickness before you go.

Gary Nelson, PMP
 

Originally posted on Gazza's Corner by Gary Nelson, PMP Thursday, 30 August 2012. Reposted with permission. All rights reserved. Click here to see the original post.
Gary Nelson is the current Director of Communications for PMINZ.

 

Project Planning 1.1: Project Tracking - Plan for it Now!

Project tracking is an important element of control on any project. During the project, you need to be able to measure and report on progress against project deliverables, and roll-up that information into higher and higher levels, until you often end up with a high-level dashboard for the Project Sponsor and other executives (red light, green light, yellow light). And in the long run, you need to be able to know when you have actually finished the project, and if you have succeeded in achieving the project goals.


Sounds straightforward, right? But as you probably already know, it is not quite so simple. There are many projects that do not track enough information, and others that track too much. All of this tracking requires effort, by the individual team members, their team leaders, the Project Manager, and those who receive the status reports.


Asking people to spend "overhead" time on activities like status reporting when they do not see any direct relation to what they are doing, and how it is used can be another big problem - if they do not see value in doing it, it becomes a "chore" that they would rather not do - so they may delay doing it, not do it at all, or worse, "fake it".


Sometimes all that effort results in only a cursory glance at the highest levels. So why bother with it? Or the information can become so disassociated due to poor structuring when it is rolled up that it becomes effectively meaningless. This problem can be a related to how you have structured your Project Plan, and also your approach to tracking. That, of course helps nobody.


So what do we track, how do we track it - and most importantly, how do we plan for it and what do we do with it?


In this session we will explore the essentials of Practical Project Tracking - what you will need to manage your project, satisfy the reporting needs of your stakeholders, and be able to tell, in the end, if your project was successful.

Practical Project Tracking

Note: I have introduced this topic immediately following the Project Kickoff rather than leaping straight into Project Plan development, because deciding what you are going to - and how you are going to track it - go hand in hand. If you build the Project Plan and then think afterward about how you might track it, you have actually started backwards and may need to do some re-structuring. You need to be prepared and thinking about tracking first - before you build the detailed plan.


If you have read any of my other articles, you will know that I like to keep things simple. I have managed some very complex projects, so it is not the projects that are simple - but any processes you use within the project team should be simple, clear and easy to follow. Make something simple and people might actually use it. Make things complicated, and you are fighting a losing battle because people will resist it. They may make a half-hearted attempt to do it at the beginning, but usage will generally fall off over time. Or the number of errors introduced because people do not understand it or how to use it will soon make any information collected unreliable.


In fact, I like to think that the more complex the project is, the simper the processes the PM introduces need to be. People's heads will be so full of all the other complex detail, it can be a relief to follow some simple steps a few times a week. They might even come to enjoy providing status to you! (Well, OK, maybe not - but they will be less likely to see it as a burdensome chore).


So keep it simple. But in saying that - you can produce some very complex statistics and other project measures using data that is collected with simple processes - so this is by no means "dumbing it down".

1. Why Track?

There is an old saying that goes "you get what you inspect", or alternately "you get what you test". If you have no way of determining what is happening on the project, what has been completed, and what issues there are that might trip you up, how can you make sure you are on track? If you are not looking (or not looking in the right places), things will continue along quite merrily - until they sail right off the cliff.


The basic purpose of tracking, put simply, is to be able to answer these three questions:
- Do we know where we are now (what we have done up to this point)?
- Are we still going in the right direction, and what obstacles might be in the way?
- How will we know when we get there?


If we have enough information to answer these three questions, whatever form(s) it might take, then we can take corrective actions if necessary, and fine tune the next steps to catch up, and/or to keep the project on track.


Another aspect of tracking and measurement is analysis/review - no point collecting information if you are not going to do anything with it. The Project Audit may see a clear path to failure in your detailed records, but it is better that you use the best information available to stay on top of things and, like a GPS, do minor course corrections as you go - vs having to backtrack a long way when you have gone too far off the planned route.

1a. Ask the Question: Why do you need it?

The next thing you need consider when planning to track your project is: "What will we do with the status information?"


"Easy" you say - "we use it to manage the project." Well, yes and no. You need to consider your stakeholders - yourself (as the PM), the project team, the Sponsor, and any other key people in your Stakeholder map that are (A)ccountable or that need to be (I)nformed on the progress of the project, and made aware of any issues that need to be escalated to them, decisions that need to be made, etc.


Your reporting requirements may be for two main groups (the Project Team and "the Sponsor and all the rest of them"), or you may have several distinct groups that you need to report to. The information that you need to provide may also differ from stakeholder group to stakeholder group.


Let's consider this further.


- As the PM, you know what types of information you typically collect on a project "of this type" to ensure you have enough information, in a timely enough fashion, to make sure the project stays on the rails, moving in the right direction, and that you still look to be "in scope/on budget/on schedule" etc.


- The others are a little harder. You might guess at what they might want, because on the last project the stakholder groups, the sponsor etc all wanted particular information. But a better idea is to ask them what they want. Each stakeholder group may need different slices or views of information - some may want to just see the financials to-date. Some might want to see overall progress as %completion, and the CEO may just want a red/green/yellow dashboard. Give each group exactly what they want - and not more than they are asking (at least for now - they may refine their reporting needs later). You should also ask them how often they want the information reported (weekly, bi-weekly, monthly, quarterly, etc).


Still not clear on what they are looking for exactly? Ask them to provide you an example from another project, or have them draw it out for you (or they describe it, you draw it, and they validate it). You may find out that the information they require might actually affect the evolving stucture of your project plan. (They may want overall or detailed status by particular stages of a long-term project, or by major deliverable groups, etc). The more you know now, the easier it will be to make sure that your project plan/WBS meets your needs - but also does not become a headache when trying to report to stakeholders.


Tip: This will become an important part of your Communication Plan.


Once you have a perspective on what the different stakeholders need, plus what you need to manage the project, you are in a much better position to figure out what you do - and don't  - need to collect in terms of information, and how you might go about structuring it. You may find that you can simply "roll up" detailed status in the project plan to satisfy some of their needs. Or you might need to do some more typing - i.e. if they need to take action on anything in the CRAIDL, particularly Issues, Decisions and Risks.


Note: We won't cover the actual Project Plan development in this session, so just keep this information on tracking in mind as you think about your project plan.


- Who needs to provide the information? This may seem obvious, but take some time to think about it. Is it the Team Lead? Or the individual team members? Or more likely a combination of both? I suggest that it depends on what the information is, and also what tools you might have available.


For anything in the CRAIDL, the updates will tend to be "textual" - that is, not firm facts and figures, but descriptions of the issues, risks, decisions that need to be addressed, or are holding things up because they have not been addressed, and the status/disposition of previously raised items. This type of information is more suitable for the Team Lead to collect and provide to the PM on larger projects; if you have a smaller project then each team member could be doing this themselves.


For progress updates against the plan tasks/deliverables, either effort-based or calendar-based, ideally this will be fed back into the project management tool "at the source". I don't tend to trust progress updates that say "55% complete" as the sole measure; often the percentage is based on gut feeling and is not meaningful. However, "projected delivery date" and "actual hours" are generally more useful measures. If 48 hours of an 80 hour estimated deliverable have been  expended on the task we can calculate 60% completion. (Sometimes it might not be, example for a deliverable that involves initial delivery and test/revision cycles, the overall estimated hours is not useful for seeing if the "first delivery" is on track; you would need to break it down).


A note of caution: Some sponsors/stakeholders tend to ask for specific information "on every project" the same way, every time. Do not be afraid to challenge them to think about what they really need this time - they might in fact need all of it, or they might only need a part of what they normally ask for on this project. Just asking this question can save you hundreds of hours of effort if you are producing status information that is not actually used. In addition, you will get better sponsor/stakeholder involvement and participation - because they see you as caring about what is important to them, and that you are being a good project steward and efficient with their time and the project $. 

Of course, this could end up with you providing more information than they previously had, depending how your discussion goes. But if you are a clever and practical PM, you will offer up metrics and information you are already needing or planning to do anyway. And they may be so delighted with your suggested status reporting that makes their lives so much easier, they may take you to lunch - or more importantly, approve the inevitable change requests you really need later on without too much trouble.

2. What should we Track?

Well, there are many things you can track. There are any number of formulas for calculating project status, ROI, progress and performance. The ones you will need to use will depend on the reporting needs for your project. You can get pretty sophisticated - even with some basic data points. Note: This is not a discussion on the application and use of those forumulas - there are a number of very good books on the topics of advanced measurement and analysis.


There are three main types of information that can be collected/measured:
a) Hard data (dates, hours, budget vs actuals, defect rates, number of versions, etc)
b) Objective information (Risks, Issues, Decisions, Descriptive status reporting)
c) Subjective measures (customer satisfaction, "mood" of the client, etc).


On a project of any significant size, you will need to consider all three categories; for smaller ones just the first two.


Hard Data Measures
At the simplest level, information is commonly collected for the following
- Completed tasks/deliverables [to date, or this period]
- Tasks/deliverables in progress
- Tasks/deliverables coming up next
- Actual hours expended (to date) vs Estimated
- Actuals vs Budget to date
- Deliverable progress vs estimate (we are going to be 2 days early, or 7 days late) 
- Progress by duration (half the time is spent, we should be half way to completion, or not)


Objective Data Measures
The other important things to remember to track, manage and get updates on regularly are in tucked away in the CRAIDL.
Constraints: Any impacting the team that need to be discussed?
Risks: any new ones identified, or recorded risks have occurred (Risk Event) or are more likely to soon?
Assumptions: As we go through the project we may need to correct assumptions or add new ones.
Decisions: Are there new ones that need to be made? Any outstanding that are holding up progress? What were the results of the recent decisions? etc.
Lexicon: This may seem a minor detail, but if there is new jargon, buzzwords or acronyms, remember to update the Lexicon. This will also feed the Communication Plan.


Subjective Measures
On longer projects, you will generally need to do some periodic subjective measures such as customer satisfaction, client or department/stakeholder group mood, and perception of deliverable quality. There have been countless projects that have delivered to specification, on time and on budget - and failed because it did not meet the subjective success measures. Of course we are not saying scope and requirements are irrelevant - they most definitely are not - but if you have a finger on the overall pulse of the client, the stakeholders/end users and pay attention to the big picture, you may have a better chance of introducing or getting a change request approved that will end up with a better result for the client - and you (as team/vendor).


Adding it up
As you see from the above, not all of your status tracking may be directly connected 1:1 to items in your Project Plan WBS. Of course they relate to it, and impact it - but some types of information will not fit easily into common project management software tools for "rolling up" to higher levels. You still need to track it though.


You can also come up with other measures that you might want or need to track, so the above list is not necessarily "complete" for all projects.


And of course, the scale of your project factors into this too - there is a significant difference to the tracking performed on a 1 month project involving 3-5 people vs a multi-year, multi-department project involving a 30+ member project team. Generally the shorter the project, the less you need or want to track - otherwise you are doing more "overhead" than "doing the project". But in the larger projects, without the tracking and cross-checking measures in place, you will quickly lose control of the project.

In short, you should only track what you need, and no more - the critical bits you know you need to do as a responsible PM, and also enough information to satisfy the stakeholders, and to ensure a smooth flow of information.

3. How do we track it?

This is a tricky one. It is difficult to find any one system that will handle tracking the three information types in one place, or in relationship to each other. I have myself built various custom project tracking tools on larger projects to try to fill the gaps, by combining the WBS identifiers/names in a database with the CRAIDL, as an integrated cross-referenced solution. That definitely helped manage the project; the team leads all had access to the database from their own PCs. It worked very well for status reporting and meetings, and discussions where we could then identify the CRAIDL items assocated with a given WBS item, or the reverse - all WBS items impacted by a given risk. It was relatively sophisticated - it tracked status updates and effective dates as transactions for all activity related to the CRAIDL items in the database.


However, it did not have all of the "hard" data - parts of it were there, but the actual hours and financials were done separately.


And no, I'm not selling a system - it's not for sale - it was MS Access 2003 based, customized for the project, and did not scale well beyond the LAN. I just bring it up as an example of what can be done, and there may be value for you in doing something similar as well.


For the "hard data" there are a variety of collection methods:
- Hours expended [timesheets] - coded by task or task group
- Per-task updates in the WBS


You might have an integrated solution like Project Server that allows you to do all of your time entry and task level updates in one place - if so this is great; the fewer touch-points the better. 


If you just have a standalone tool like MS Project, definitely structure your plan so that it is simple for you to apply the status updates from your team - your own time is very important - you need to be running the project and communicating with the team, and spending "only just enough" time as is needed for your status reporting tasks. (Note that this part of your definied activities and should be in the communication plan - it only becomes "overhead" if you have to spend too much time doing it).


Tip: Whatever you do, design your measures/collection methods so that it is only input once. It definitely will be a chore if anyone has to put the same type of information in more than once.


The CRAIDL items can be tracked by spreadsheet, or put into a database. Or you may already have a system that will do this. I would recommend, however, that you try to track it in a database on larger projects - it will make the ongoing management easier, and more importantly, more visible. If you have the information quickly available when a risk event occurs, for example, and you know which items will or can be impacted, you are better able to respond.

The important thing is that you, as the PM, need to determine the best way for you to have the information collected, and that it comes to you in a usable form without too much manipulation. You will also want to ensure that form also lends itself to feeding "up" to the various stakeholders as well.

I made it a goal to be able to produce the various status reports in less than an hour a week; of course some automation helps (and I spent many "free time" hours building the system up front, but it did pay off as the project ran for more than 3 years). But even doing something as simple as providing a status reporting template to the team leads that they can easily fill in - and you can copy/paste into your master report - is a big step in the right direction.

These days, I am dealing with high-volume, shorter duration projects, and they have their own unique reporting needs. Again, I built a system - based on Sharepoint - to suit our specific needs; it does not have all of the CRAIDL elements this time, but it has been structured so that there are minimal touch-points for team members (less of a chore), and has a sophisitcated workflow engine to keep things running smoothly. It supports near-live status reporting, because team members updating status and hours are immediately available as they complete their tasks. It has also been structured to serve as the project system/business support stystem, and drives invoicing as well. Financial audit? Capacity Plan/Forecast? No problem - query to a spreadsheet and all of the detail is there for you to work with. 

Note: If you are interested in doing a system like this yourself, I have a free 9-part Sharepoint series on "Custom Project Systems on a Shoestring". Your specific needs will likely differ but the methods and principles will be the same.

What about the Project Plan?

At the beginning we mentioned there may be impacts on your project plan design, dependent on what you need to do for status reporting. This specifically applies more to the "hard data" measures, where you want to make sure that you can "roll up" the data to higher levels in a form that both makes sense to you, and to your sponsor/stakeholders.

There are many ways to build a project plan, all of them reasonable - but if you know how you are going to need to report status and progress, you will make different decisions on how you structure your WBS. 

- Will your top levels be functional areas?

- Will you have stages and then functional areas?

etc.

There will be further discussions on this topic in the next session - Project Planning 1.2: Building a Practical Project Plan.

Summary

 I hope you have found this session useful for your [upcoming] projects. As you can see it is difficult to describe a specific concrete solution that will satisfy everybody and all projects. But that, I think, is the point - on each project, you need to assess the lay of the land, and determine from the beginning what you will need to do for this particular project - and how much tracking will be needed. The goal is that fine balance of "just enough".

A final note - if you think that tracking some particular bit of information would be worthwhile because it "feels right" (or it kept you up at night thinking about it), even though can't see a direct reason right now - do consider including it. Your experienced gut may be telling you something. If you find later on that there are some things that need "less" tracking, you can taper their use off. But it is hard-to-impossible to go back and collect information after the fact - i.e. months later, if you did not do it in the first place.

And of course - think about who is going to be providing you all that information. Be wise in your requests on their time, and also make it visible how their information contributes to the overall health and success of the project.

So plan your tracking and measures, but be practical about it.

Good luck with your projects.

Gary Nelson, PMP
Originally posted on Gazza's Corner by Gary Nelson, PMP Wednesday, 25 April 2012. Reposted with permission. All rights reserved. Click here to see the original post.

 

Developing Exceptional Requirements: Lessons Learned from Ice Cream and the Spice Girls

By Gary Nelson, PMP

One of the things I looked forward to most on my business trips from Canada to New Zealand was a little town called Pokeno, south of Auckland on the edge of the Bombay hills.

Pokeno is famous for two things: Bacon and Ice Cream, most definitely not in that order. Pokeno used to be right on SH1, and everyone travelling to or from Auckland and the Waikato went through it - right beside the butcher and two of the busiest ice cream stores you have ever seen, summer or winter. And even though these ice cream shops are literally side by side, neither of them suffers in the least. Today, even though the SH1 is a newer road bypassing Pokeno, it is still as busy as ever, with people making sure to take the off-ramp into the little town.

There is nothing special about the ice cream itself - you get the same brands in the grocery store. Nothing special about the service either - and you only get the one tiny napkin wrapped around the cone, and no spares on the counter.

What made Pokeno famous - and still does today - is that they have the cheapest, largest scoops in the country. And 42 flavours to choose from! Not only that - you can have up to 11 scoops at once (on one double cone base) - for only $8. I am not kidding. It would be literally about a foot high at least, above the cone. I haven't tried it myself, as 2 scoops is plenty for me, but you can be sure my kids have been sizing it up as a worthy challenge.

These are by no means tiny scoops either - in Canada and the US you generally get a modest scoop most places you go, except perhaps the "premium" shops, with premium prices. Here you get good, honest scoops, twice as wide as the cone itself - for once, actually bigger than the pictures suggest.

I am getting hungry just writing about it!

Anyway, this article is about writing Excellent Requirements - and yes, it does relate to the Ice Cream. One of the challenges in Pokeno is there is a lot of choice - 42 flavours, 11 configurations (1 to 11 scoops at once). That is a lot to wrap your head around, and don't forget the Sundaes.

We have similar issues with eliciting and documenting requirements on projects - we need to get down to the details of what is exactly needed by the customer. When everything is shiny and new, sometimes customers simply want it all...and sometimes they kind of know what they want but can't commit to a specific choice and option.

Chocolate, Dutch Chocolate, Dark Chocolate or Triple Chocolate Chip?

Cookies and Cream, Gold Rush, Peppermint or Goodie Goodie?

Wait, let me look at the other 34 flavours first...

And which one goes best next to Liquorice?

It is so hard to choose...we need some help!

What we need is...a good Requirements Definition Process.

Tell Me What You Want, What You Really, Really Want

I have to admit, The Spice Girls nailed the key elements of a very successful Requirements methodology with their lyrics "Tell me what you want, what you really, really want". 

Well, maybe not the whole song - perhaps just the chorus.


But it is definitely about Requirements - and we do have some lessons to learn from them.

Project scope, RFP, user needs, specifications... these all are variations of customer requirements. We definitely need them, so that we know what we are supposed to deliver. But when do we know we have enough requirements? How do we determine that there is sufficient level of detail before the requirements get signed off?

We need  to get into the details - and in the most effective, efficient way possible.

A successful Requirements gathering methodology involves three main steps, that progress from higher to lower levels of detail.

Tell Me ...

Generally it is sufficient to kickoff off your project with very high level requirements, so that everyone has a common "big picture" understanding of what it is we are trying to achieve. However, once you actually start the work of the project, these requirements must be refined into finer and finer levels of detail.

I want Ice Cream! Lots of Ice Cream!

Part of the project planning should include tasks and the associated investment of time and effort into the requirements refinement so that the project deliverables can actually be designed, developed and delivered. Not only that, but the delivered items should match the business need. So hopefully we can collectively nail down the requirements clearly enough with the customer that when we do develop exactly to spec, it is exactly what they asked for - and is what they actually want.

You look at the board, the size combinations, and realize that you might not be able to eat 42 scoops at once. Maybe not even 11.

I need to think about this a bit...

...What You Want...

I think we have all had the experience of delivering something to a customer (hopefully on-time and budget) and having them say "yes, I know it is what I asked for and you delivered it to spec, but it's not what I wanted!"

So the solution is apparently simple then - just find out what they want, document it, and then deliver it!


Boy that Ice Cream looks good. I like this flavour, and this flavour and this flavour - and...oh wow! I haven't had that since I was a kid, better get that one too...

...And yet here is where we run into some major stumbling blocks that have to do with Communication and Expectations, seemingly no matter how hard we try. The key issues generally are:

1. They think you know what they want, in great detail... from the vague outlines in the Project Charter, RFP or High Level  Requirements. Oh, plus the word picture they gave you months ago while standing in line for coffee at Starbucks. You must understand what they need from that! They certainly described it to you well enough...right?

2. They think they know what they want... but sometimes they don't - at least, not in full. This happens more often than they will admit.

3. They don't know what they want. At least, not yet. This happens often - and especially when a customer is migrating to a new system. They know how the old system worked, they know what they could produce from it - and they don't yet have a full understanding of how the new system functions or what it can do.


4. We don't know what they want. It is generally safe (and wise) to approach the project with the attitude that you don't know exactly what the customer wants, at least, not in detail - so approach it with open eyes, ears and mind, asking questions.


5. We don't know what we don't know. It is inevitable that even with a rigorous requirements collection model, things will be missed. People may forget to bring them up until later, not on purpose of course, but because they forgot.....or sometimes, we just don't have enough information yet and it is truly an "aha" moment brought to the table later on.




Ok, so I think I can handle three scoops, or maybe just two. They look pretty big. 

Getting Down to Brass Tacks

We need to break the bonds of assumptions and pre-conceptions of "this is how we used to do it" and get down to what it is they want - in words that both the customer and you can uderstand - and hopefully agree on the same meanings for the same words.

Gather as much detail as you can at this stage - and WRITE IT DOWN!  If possible, collect samples, photos, screen shots, diagrams, anything that will help remove ambiguity from the requirements. A picture may be worth a thousand words, but a screen shot or report sample definitely does not cut it on its own - there is an iceberg worth of business logic detail hidden beneath that small sample.

So, we sit down with the customer, talk to a few people, write things down and thereby "document the requirements". Many people stop here, shake hands all around, get the specs signed off and get ready to start designing and building. Mission accomplished!


Well, not quite. In order to make sure we have covered the bases, we need to validate the assumptions around the requirements to make sure nothing was missed - before signoff.


We need to check and ensure that what they have asked for, and what they have documented as "what they want" is also what they need.


I have five favourite flavours, now I just need to choose which ones for today's masterpiece...
 

...What You Really, Really Want!

In my experience it is often the case that the users or persons responsible for writing the requirements (either with or without you) know what they want, but they don't always know what the end users need. But they think they do - and therefore, so do you.

"What's that?" you say. "Of course they know what they need. They are writing the requirements so what they write simply ARE the requirements. What they want is what they need."

Well yes...and sometimes no. As thousands upon thousands of Change Requests every year around the globe will attest.


Sometimes they have difficulty articulating their actual needs. Sometimes the language they use relates to how things were done in the past and do not translate well into the new environment. Sometimes the customer's language is not your language, (project or domain-speak) and there are misunderstandings. The words on the page may read exactly as the customer believes it should be - but the vendor interprets them differently. So a "read-back" review of the requirements with both parties is an excellent idea - it helps ensure that the words on the page are interpreted the same way.

And quite often, they simply forget to write things down because of the embedded culture...meaning "well, everybody knows about that part because it is just they way it is around here" ... and things get missed - especially if you as the vendor/contractor are not part of their culture.


In our Ice Cream example, everyone assumes that you actually want Ice Cream. Who doesn't? Well, if you are Lactose intolerant, you might buy some dairy-free sherbet, or just go next door and buy some Bacon. (The good news? Yes they have Sherbet too! No Gelato, sorry.)

The truth and your project salvation lies in the questions...lots of questions. And without those questions we are often lost in translation.

"What they want" is not the end game. "What they Really Really Want" when you dig deeper is more representative of what they actually need. Sometimes you may find that these indeed are one and the same thing - and the customer does have an excellent grasp on what they need, and articulate it well. And sometimes, that little bit of digging deeper will save  thousands of dollars or hours of rework (whether or not it is a paid change request, it is still better to be able to meet the need the first time).


"There is never time to do it right the first time, but there is always time to do it again." - Unknown


If you dig deeper and challenge the customer's initial presentation of the requirements, especially as they are translated into the new system, you have the opportunity to make sure that you have been thorough. However, you also have the opportunity and responsibility to identify better or more efficient ways of satisfying the need, while still staying in budget etc.

Which type of chocolate scoop do you want? Chocolate, Dutch Chocolate, Triple Chocolate Swirl?


If you can do this and do this well, you will also gain a reputation for someone (or a firm) who are good at getting to know what their customers need, and can deliver. Now, what customer would not jump at that? Word-of-mouth referral is a powerful tool.


"It takes less time to do a thing right, than it does to explain why you did it wrong."  ~Henry Wadsworth Longfellow

Sometimes those "missed requirements" are small omissions with small change requests, but sometimes they are big ones.

You can't un-scoop an Ice Cream if you changed your mind.

The Cost of Requirements Change

We have all heard about how the cost of change increases significantly the further you are along the path of delivery. If the unit of effort to make a change to the requirements is (1) at requirements stage to accommodate a change, then in design it increases to (2-5X), in development it jumps up (to say, 10-20X) and once delivered it increases again to (100X+). Or perhaps a different scale may apply in your business, but you get the idea.

With one of our recent clients, there was a piece of custom programming work that went through a formal requirements process, reviews, signoff, development, delivery, testing...it was on the verge of acceptance when one of the end users identified that they did not want whole numbers (Integers) on the report output, they were supposed to be decimal (xx.xx) numbers in a particular type of result.


 In most situations, this would be a relatively minor change. However, in this case, due to the complexity of the overall report code, and the specific and unique solution developed to accomplish what was required, this was not a simple change. In fact, in this case it was a HUGE architectural change that required a full redesign of the report and the coding logic.


The solution to satisfy the new requirements ended up being even more complex than the original.


This might be a 1 in 10,000 case, but in this specific scenario, if the original estimate was (X), the cost of the rework was actually (X*1.1), so the TOTAL cost of the custom report ended up being (X*2.1), or 210% of the original estimate.


When you change your mind about flavour after you have started eating or have finished the cone, you need to buy a whole new cone...you are not just asking for a few sprinkles on top.


An extreme case perhaps - but still true. Missing the fact that they needed the decimal places vs integers at the outset was an acknowledged requirements failure by the customer, but it was still a very expensive mistake.

So, Ask The Questions...

It is incumbent upon the project manager to ensure that all of the right questions get asked ... Lots and lots of them... And the earlier in the project the better.


How many scoops? (So they choose the right base)

It is through the interactive dialog that great requirements can be elicited and documented. The better you are at asking the questions and understanding the big picture and the detail level, the better your requirements will be. This has the benefits of:

- Better estimating process

- Better initial quality

- Less rework / waste

- Lower overall cost (time, effort, $)

- Delivering what the customer needs
- Better reputation for insight and delivery


Ice-Cream? Sherbet? Which flavours? ...And FYI the Bacon is next door.

...And Remember to Actually Read And Use the Requirements!

When you have the requirements, good ones or exceptional ones, you can still fall flat on your face. When you are executing (designing, developing, building), make sure to read, re-read and read the requirements again. And before you say you are ready to deliver to the customer, re-check the requirements to make sure you have done it right, to the specs.

And if you come across something that looks odd or not quite right, or incomplete - raise the red flag and ask questions. Clarify the requirements with the customer. There may be a question of interpretation , there may be a clarification needed, or there may actually be a Change Request needed, if the requirements don't accurately match the need based on current information. 

Remember, the cost of making the changes to your project deliverable get increasingly higher the longer you wait - so after you have re-read and you are still not sure - ask the questions as soon as possible - and if a Change Request is needed, better to catch that in Design than Development, better in Development than in Testing, and better in Testing than in Production.

Summary

"Good" requirements analysis and documentation is often not good enough. You need to go that extra step to validate that what they are asking for is actually what they need. So work closely with the customer, and follow the three-step process towards developing Excellent Requirements.


1. Tell Me
2. What You Want
3. What You Really, Really Want!


Don't stop at #2.Too many people do.

And once you have those artfully crafted Requirements, make sure to follow through with a flawless delivery - checking against the requirements, and also looking out for when "what they ask for" might not be "what they need".

Today, I am going to have two scoops, Dutch Chocolate and Orange Chocolate Chip. Next time, I may choose the Mint Chocolate Chip and Rocky Road. Now that I actually live in New Zealand, Pokeno is not that far away!

Decisions, decisions!

Good luck with your projects, and keep an eye on those Requirements!

Gary Nelson, PMP

Originally posted on Gazza's Corner by Gary Nelson, PMP Friday, 22 June 2012. Reposted with permission. All rights reserved. Click here to see the original post.

Gary Nelson is an independent IT consultant and Project Manager, and is the current Director of Communications for PMINZ.

Project success and the role of good estimates

By Peter Young, PMP
 
As project managers, we crave the same thing – we want our project to be seen as a “success”, by the sponsor, business owner, governance, the team, end-users, ... everyone.

Successful projects deliver benefits, within constraints including scope, time and cost. To be seen as a success, a project needs to start out with good estimates of the time required to deliver the scope, and the cost of that time.

A key finding of KPMG’s NZ Project Management Survey in 2010[1], was that projects undertaken by New Zealand companies often perform poorly in at least one of the following areas – lack of timely delivery, cost over-runs, or inability to achieve the stated deliverables.

The survey found that only a third (36%) of NZ organisations reported consistent on-time delivery of projects, and only half (48%) reported projects being consistently delivered to budget. Internationally the Standish Group found only a third (32%) of all projects were delivered on time, on budget, with required features and functions. NZ project success rates are not unlike elsewhere.

As Project Managers, we are not enjoying “success” as often as we would like. At least some of the reasons for this can be traced back to how we go about preparing our estimates of time and cost to complete the project.

When looking back on a successful project, the following features will often be found to be true:

• During planning, the scope was broken down into detailed requirements that were measurable (testable). This ensures everything gets estimated, and the estimators are clear on what will be an acceptable deliverable.
• Estimation time was adequately budgeted, and a sound process used. It takes time, and a good process, to do a good job of estimation.
• Estimates were provided by the people who did the work. This ensures estimates reflect the work rate of the people involved, and helps to get their buy-in.
• Estimators understood the work and were able to estimate it accurately. Possibly the most challenging aspect of estimation. Get data on similar projects, to enable comparison. It also helps to break the work down into less complex tasks that can be more readily estimated. If in doubt, get advice from someone with more expertise, either in estimation techniques, the work being estimated, or both.
• Actual delivery was regularly monitored against the project baseline, to validate that the work accomplished matched the plan. Where there are variances, re-forecast completion time and costs. This enables you to signal early if the project is likely to run ahead or behind on schedule or budget, and creates the opportunity for the project schedule and budget to be adjusted (using appropriate change control).
• Scope variations were quickly identified and managed. Volumes can be written on this topic, and experienced project managers know that scope creep will torpedo the success of a project. The mitigation for this involves good communications within the project team and with stakeholders, an effective change control process that enables request for changes to baselines to be identified, assessed, estimated, approved or declined, documented, and communicated to all those that need to know.
• Risks to the project were identified and managed effectively. Risks and issues need to be estimated, either quantified as time and cost, or at least identified qualitatively in a risk and issues register, enabling allowance to be made in project contingency estimates. Under-estimating risks will lead to insufficient contingency time and costs, which in turn can lead to under-estimation of schedule and budget for the project.

This is not an exhaustive list, you may have tips and techniques of your own that contribute to project success. Consider sharing the benefit of your experience with the wider project management community. See below for details on how to submit an article to PMINZ eNews.

Good luck with your project estimates, may all your projects be seen as successes.

[1] For the full report, see www.kpmg.com/NZ/en/IssuesAndInsights/ArticlesPublications/Documents/Project-Management-Survey-report.pdf

Peter Young has managed business focused IT projects in the Wellington government sector over the past 5 years, and prior to that 25 years in international and local roles in the oil industry. He has held several volunteer roles with PMINZ and is the current Central Branch Chair. All rights reserved.

A Leader Without Followers is Just a Person Going For a Walk

By Allan Old, PMP

So how do you get others to walk with you ?

You have to know where you are going and know that you can’t get there by yourself.

You have to convince others that the goal is worthy of obtaining and that you need them.

This has to be done with integrity and be believable.

Share the vision
What and Why. The what can be attractive, but the why is more important.

Get a team together and determine the basic principles that the team will operate under. This aligns the values of the team and the individuals with the why of the undertaking. Get the team to determine the how.

You may think you know the answer but by asking open ended questions team members will be able to provide input and then the resulting plans will a shared outcome. The quality of your questions will determine the quality of the answers. Become a better questioner.

Leaders manage the task and the sequence, provide the support and ask the people for outcomes. When asked to make decision, unless the consequences of a delay are serious, a leader will ask a question to maiximise the learning opportunity.

Think about those who you thought were good leaders. Did they tell you what to do or ask you?

Allan Old is a Project Manager at Alcatel-Lucent with over 20 years experience in change leadership and project management.

Authentic Leadership in Project Management

By Sean Whitaker, PMP

There are many aspects of project management that contribute to project success. There are the technical skills learned and the experience gained in applying them. There are also the soft skills such as communication and influencing that a project manager must possess. Perhaps most important amongst all these skills is the ability to lead and demonstrate leadership, particularly authentic leadership. A good project manager manages a project; a great project manager leads a project.

Leadership is the purposeful, influencing of followers. Without any of the three key elements is simply isn’t leadership. Without purpose, it is someone we may wish to follow who doesn’t want to lead. Influencing acknowledges that the leader has a vision and influences followers to go in a particular direction. Followers are the most important part of the equation though, for without followers there are no leaders. Great leaders respect their followers and great followers respect their leaders – it’s a mutual relationship. Leadership is a conscious deliberate decision. It is an acknowledgment there is a relationship between leader and follower, and each needs the other to exist. It is a commitment by those who choose to lead of continual personal and professional development. It is a commitment by those who choose to follow of support and feedback.

Leadership requires many different competencies to be displayed at different times as it is highly situational. The competencies you must display during times of high stress and challenge will be different from the competencies you must display during settled and stable times. However, the one core constant aspect of leadership is authenticity. Being authentic means having integrity and not pretending to be something you aren’t. People will always know when you are not being authentic. Being authentic means having a set of values and living them. Don’t be the ‘do as I say, not as I do’ type of leader. Being authentic means having a genuine interest in people and especially your followers. Begin authentic means having a balanced assessment of your own strengths and weaknesses.

It has been proven that good leadership enhances the chances of project success and the absence of leadership negatively affects the chances of project success. So if you want to increase the chances of project success practice your leadership skills and recognise that the best sort of leadership is authentic leadership so be true to yourself. Be true timber, not a thin veneer. 

Sean Whitaker is the current President of PMI New Zealand and author of The Practically Perfect Project Manager. Sean is also the co-owner of Falcon Training and spends his days teaching, speaking or writing about project management.

Leadership: Ten Attributes of an Effective Leader

By Gary Nelson, PMP

[Also available as a Podcast]

Effective Leadership

No, it is not a myth. Many of us have actually seen this phenomenon, or even been lucky enough to work with an Effective Leader. If you were really lucky, they were also your manager/ team leader/ project manager etc.

Ok, to be fair, Effective Leadership is not quite that rare - but uncommon enough that people definitely appreciate it when they see it - and they wished they had it too.

My experience with an Effective Leader

1989 - Back at the beginning of my first career, straight out of University, I was quite fortunate to be hired by an Effective Leader. Of course, I did not know that at the time, but as time went on this became more and more apparent as teams came and went - and his stayed together. 

We identified with him, the team was loyal to him, even through a multi-year dissolution of the company into fragmented parts - in part, because he was also loyal to us. In the final stages of the corporate sell-off, while other departments in our part of the business saw an attrition rate of 70-90% over a 6 month period, his department lost only 2 people in the same period of time. And those only did so after long soul searching on career direction.

Over a period of 11 years, his team stayed together, until he recognized a strange truth - in order for his team to grow further on their personal development paths, he had to leave the company.

In our case, we not only had an Effective Leader, but an exceptional one.

So what makes an Effective Leader? And does that person need to be "the boss"?

Ten Attributes of an Effective Leader

1. Ethics

An Effective Leader has a firm ethical compass. They stick to what they know is right, even in the tough times, and do not easily bow to social pressure or fads. They also make sure that their team embodies the same ethics - honesty, looking out for the customer, doing the right things - right, etc. And not a "closet ethic" - it shows in how they conduct themselves every day.

2. People Skills

An Effective Leader has good people skills, and can communicate effectively with their peers and their team, as well as up and down the corporate ladder. They don't have to be a gracious public speaker to hundreds or thousands, but they do communicate well within their sphere of influence. And Exceptional Leaders develop a significant sphere of influence.

3. Not the Boss

In those 11 years, except for a few periods while on projects with a different department, I did not have a Boss. I had a Manager, a Coach, and a Leader - not a "Boss". An effective leader works with their team, encourages and supports them. Sure, there are plenty of times the leader needs to have things done a certain way, in a certain time - but the difference lies in how they communicate it. A Boss demands the work be done - a Leader requests it and expects it do be done properly - and those working for them are dedicated to doing just that.

4. Praise in Public - Criticize in Private

We have all heard this mantra - and it certainly makes a difference not being "dressed down" in public. However, an Effective Leader takes this one step further - when discussing issues in private, the Effective Leader rarely brow-beats their team member - even if they want to. They address the issues, the behaviour - whatever was at fault, but in a way that does not rip the team apart. If anything, their expression of caring for the team member while firmly addressing the issues at fault further strengthens the team and engenders loyalty and respect. Yes - you will be held accountable, Yes - you are expected to do things right/on time/etc. No - your Leader is not a push-over, and you cannot "get away" with poor performance or behaviour. But you leave the conversation wanting to improve/fix it - you want to live up to their higher expectations of you.

5. Formal vs Informal Authority

An Effective Leader knows how to get the job done - and how to use their formal authority as well as forms of informal authority (primarily influence). As we know, formal authority is bestowed with a title/job description, and not always respected fully if the person does not behave in accordance to the expectations of the role. You may "have to" do what is asked - that is more "Boss" talking. However, an Influencer gets things done by those around them by earned influence and respect - and people wanting to help. Exceedingly happy to help, even - because they know they can rely on the Effective Leader to help when they need it. A formal title may change - but influence tends not to fade that easily.

6. Loyalty

An Effective Leader both demonstrates and earns loyalty - through consistent interactions with their team members, standing up for them, and expecting the best from them. They are great people to work for (and with), but they are not just an easy-going smile-a-lot, they are firm when needed too. They will stand up for you with the higher-ups and with other departments, but they also expect you to live up to their expectations as well.

7. Consistency

An Effective Leader does not change their stripes according to the day - you can rely on them to be consistent in behaviour. Even when they have a bad day (and we all do), they do not completely change direction, and do not lash out at the team when frustrated. You know what to expect in your dealings with them - on good and bad days too.

8. Encouragement

Effective Leaders help to grow their team - collectively and individually. They support team members trying new things, advancing themselves by learning new skills - and providing opportunites to practice their new skills in the workplace. And it's OK to fail - if you are learning something new, you willl not get it right the first time. An Effective Leader understands this, and helps you to progress to the next level, without knocking you down a peg for failing while trying.

9. Not the Detail Expert

Effective Leaders are not the experts in what you do at the detail level. Maybe they used to know it once, but that is no longer their role - they know their value lies in orchestrating the team of experts to perform at their peak, and deliver the goods - on time, with high quality of results, etc. They become experts in working with people instead.

10. Caring

Finally, an Effective Leader cares. About the team, about the company,  about the customer, about the result - and about You. You can see this whenever you work with a team led by an Effective Leader, there is a whole different nurturing atmosphere. People want to be there, and are happy to do whatever it takes to succeed - because they are making a difference and know they are appreciated.

Summary

Nobody is perfect, even Effective Leaders. However they are consistent in what they do, and they do it well, which you can see by looking at the people that surround them. You might also say there are more attributes of Effective Leaders, and I would agree. If pressed, I could also boil it down to two main words - Caring and Consistency. But in truth, there is really so much more to it as you see above. 

Can we all learn to be Effective Leaders? Certainly! Few are born as Effective Leaders, those who have a high natural aptitude for it. Most Effective Leaders start out as good observers of people, and can learn the extra skills along the way. And having a good role model/mentor and exposure to Effective Leaders certainly helps too.

I have had the good fortune to work with (and for) an Effective Leader for a good portion of my career, and when I am uncertain of what to do in some leadership situations, I think back and ask myself "what would he do?". 

Am I an Effective Leader? Honestly, I can say not yet - though I am on the path and still striving to be closer - still wanting to live up to the expectations planted over two decades ago.

To my Mentor, Coach, Manager and Friend (you know who you are) - thanks for being a great example. Your infuence continues.

Originally posted on Gazza's Corner by Gary Nelson, PMP Wed, 24 March 2012. Reposted with permission. All rights reserved. Click here to see the original post.
Gary Nelson is the current Director of Communications for PMINZ, and is an independent IT consultant who has worked in the Telecom and Student Information System sectors since 1989.