The League of Project Superheroes By Kerry Wills Growing up I used to watch cartoons about superheroes who had super powers. One of my favorite cartoons was the “Justice League” which included such greats as Batman and Superman. To overcome adversity the Justice League usually had to combine their unique super powers (e.g. Superman flying and Acquaman [...]

Credit: http://500motivators.com/motivate/me/motivation-its-not-that-im-lazy-i-just-dont-care/

AMP = Autonomy, Mastery, Purpose.

Now this is a power-packed acronym! These three words power the engine within us that takes us to greater heights, and help us achieve self-actualization in the personal and professional environment.

Located at the peak of Abraham Maslow’s hierarchy, self-actualization is described in the following way:
“What a man can be, he must be. This need we may call self-actualization…It refers to the desire for self-fulfillment, namely, to the tendency for him to become actualized in what he is potentially. This tendency might be phrased as the desire to become more and more what one is, to become everything that one is capable of becoming.”

 
Why is this stuff important?

• Supporting innovation and experimentation without punishment is crucial to personal and professional success. An environment that supports ‘test-drives’ allows people to close in on what seems an impossible task.
• A ‘purpose-driven’ (not solely money-driven) approach makes what we do meaningful. An overload of seemingly monotonous work that isn’t engaging anymore is a productivity killer. Opportunities that allow one to explore and master new areas puts a spring back in a one’s step.
• The journey is, quite often, more significant than the destination. Experience and personal achievement are, without a doubt, the more distinguishing and memorable aspects of our lives.

During a class I was in earlier this year, the instructor played an RSAnimate video adapted from Dan Pink’s talk at the RSA to drive home a point. The video reinforces what really motivates us. If you haven’t come across this video yet, I recommend you watch it here. If you’ve watched it before, well, watch it again to remind yourself what it’s all about.

This week, my blogs are going to dissect AMP and take a look at why so many of us do things, not for money, but for the sheer joy of fulfillment and learning. AMP is a powerful influence over human lives that often goes unrecognized and under-appreciated.
 

As you can probably tell from the title, this blog post is very specific - and also a very valid thing to consider when working in short iterations. Your team have committed to deliver a specified number of story points in the current sprint and part-way through a team member announces that they need to take a few days annual leave. How does the team deal with this?

For me, the first stop is a management assessment of the request. If someone needs to attend to a family emergency, for example, then it may be that you can't (and shouldn't) even consider denying the request for leave. Regardless of what you decide (or whether the request for annual leave is a true emergency) there are a number of other things you may wish to consider doing:

• Have a conversation. Agile ways of working promote conversations as part of the 'process', so get the entire team around the whiteboard to discuss the annual leave request. If the request is granted, can the team still deliver on their commitments? If the answer is 'yes' then maybe you don't have a problem (provided the remaining team members are still fully bought-in to delivery). If the answer is 'no' and the request for annual leave is not related to an emergency situation then team pressure can be an incredibly useful device in persuading the individual that they, along with everyone else, made a commitment that they need to deliver on, i.e. that taking the leave is not appropriate.
• Ask the individual to put in additional effort between now and the date of the leave to ensure that the team can still deliver.
• Consider de-scoping features. If the request for annual leave is urgent and simply cannot be denied, then you may have no other choice. It's as simple as that. 
  • Even where the leave is not critical, you may choose to grant the request anyway. In doing this, you need to be very careful of the message that this sends to both the other team members and the business. Is it really worth it? Personally, I would shy away from this option in a non-emergency situation.
• Agree to play it by ear. Do you need to make the decision right now, or can you see how much progress the team is making in 1 to 2 weeks time and then make the call?

Thoughts?

Yes, we have snow. Like almost everybody else. The neighbors created an ice-skating track by flooding a small field. The ice is not perfect. But … it’s just perfect. People get together. The field of frozen water is just a good excuse to get out and have some fun.

It’s not that if there isn’t an ice-skating track you don’t meet. But this is just such a great opportunity. And a natural one. You don’t have to plan. You just go there. Show up. That’s it. The track is a catalyst for conversations.

Communities have more places like that. Libraries for example:

“For some, the building remains essential: engagement with the library is a ticket to – and a membership card for – a local community. Some say the building needs to be there, but not as “a warehouse of dead books”, but as a place to invent yourself, individually and socially.”

In some weird and twisted way, back in the days when I still smoked cigarettes, the smoking area in my company had a similar function for me: I was the most informed Project Manager around. I knew a lot of people that weren’t in the direct surroundings of my project. It’s not that the individuals weren’t approachable. It’s just that I am not the kind of guy that is randomly stopping people in the hallway to ask what they do.

Organizations have these natural places where people bump into each other.

Coffee corner. Lunch room. Places where you experience that you are part of a certain group, just by having the same rhythm. “Hey, we drink coffee in the same pace!”

Architects can actually design these places.

The best we can do is recognize the opportunities. Or make use of social objects:

“For a while I  had  a bowling bag to carry my papers and other work related stuff. I bought it, because everybody else was carrying the same black Samsonite briefcase. The bag was blue with white letters and oddly shaped. Colleagues and clients would say something about it. Complementing me on my fine exquisite taste. Making fun of my stupid bag.

The bowling bag created engagement. A conversation starter. Something to trigger a spontaneous moment of interaction. And never in a negative mood. The plastic bag from the supermarket I carried around for months after that triggered some different comments though.”

Image by Frau Shrink.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - An Ice Skating Track And Opportunities To Start Conversations. is a post from: Project Shrink.

- what would it take to differentiate yourself and your project from others? What would the value be?

To most project managers and professionals my guess is that the word ‘brand’ evokes a certain sense of ‘marketing non-sense’ and ‘showman-ship’. Why would a project or even worse a project leader need a ‘brand’?

As it turns out, the project management world has an opportunity to learn from our product and brand management colleagues. The value and equity we can derive from ‘marketing’ our project using a brand can help set it apart from others and help get our project prioritized and noticed.

MIT Sloan’s – Management Review recently put some focus on this in an article titled “Why Every Project Needs a Brand (and how to get one). In reference to the project brand they wrote, “Broadly speaking, a brand can be defined as a unique value proposition expressed in a relevant and differentiated way such that it creates preference and loyalty among key audiences. So why is project branding important? Because your project can suffer in the absence of a compelling brand.[i] “

(source: .http://theclosetentrepreneur.com)

So, what are those key pieces of information that project leaders can learn to leverage so your suffer in the absence of a compelling brand? Here are a few to start with, if you have others that you would like to share, feel free.

Project Naming: this is the brand management process of deciding what a product will be called. A project manager can think of her project as a product, considering the stakeholders and the project members. Naming a project or product is a critical part of the branding process, it will help everyone involved to identify with the vision of the project and to be consciously reminded of the future outcome and benefit of the project When naming a project you must take into account the many uses of your name in documents and dialogue and ensure that it is a name that helps people to ‘get it’ easily.

The process of naming your project should be done deliberately and by involving your team members, ensuring that it is something they will be energized and inspired by.

Some key steps include specifying the objectives of the branding, developing the project name itself, evaluating names submitted by the team, and choosing a final name.

When brainstorming about a project name, the following ideas might be useful:

• it strategically distinguishes the project from other projects by conveying its unique positioning
• it holds appeal for target audience
• it implies the project’s future benefits and outcome
• it helps to motivate team members to work on the project and helps executives to promote it.

Selling a vision: Just as brands help those who market products or companies convey the purpose and value to their target audience, so can a project manager help convey the vision of their project through a brand.  In most cases your project is competing for attention and funding with many other projects and you with many other project managers. Developing a brand for your project and maybe even for yourself can help you set yourself apart and help you convey your vision, benefits and value or your project. To help you get started, spend some time thinking about statements in the following four areas that help you convey the project:

1. Unique value proposition – what is the unique value your project is bringing to the table
2. Unique selling proposition – your elevator pitch
3. Slogan or Mantra – what is going to make it easy for people to know what you are working on
4. Positioning statements – targeted towards different people you may encounter

(Source: http://craigpearce.info)

Brand Equity: in essence the value you get from employing a brand for yourself and/or your project versus those who do not spend the time doing so.  Thinking about the brand equity you may be building through your efforts can help determine if the time and investment is worthwhile compared to your peers and competing projects.

According to Wikipedia, Brand Equity is “the marketing effects and outcomes that accrue to a product with its brand name compared with those that would accrue if the same product did not have the brand name. Fact of the well-known brand name is that, the company can sometimes charge premium prices from the consumer.”[ii]

How might this translate into a project management setting? If the process of branding is done correctly for your project, it might mean that when funding decisions are made by your executive team, you would see additional benefits by the “awareness” of your project and garner opportunities to showcase your project and its benefits/outcomes/value in forums not otherwise open to you.

[i] http://sloanreview.mit.edu/the-magazine/2011-summer/52416/why-every-project-needs-a-brand-and-how-to-create-one/

[ii] http://en.wikipedia.org/wiki/Brand_equity

- a set of familiar tools seen through the eyes of a product manager

- By Sridhar Karnam (www.linkedin.com/in/sridharkarnam)

Tools that product management use that might be interesting for project managers to use:

In continuation to our last week’s discussion about lessons that project management can learn from product management, let us examine some of the tools that product management uses that could assist in project management:

Weekly newsletter: The communication within the team and between team is critical for product management. At a simplest form product management uses email, wiki, idea management, and requirement management tools. Project management could use simple tools such as weekly newsletter to communicate the status update with the entire team, with the management, and also between other project teams to ensure that everyone is on the same page. Program manager is typically responsible to bring every project on the same page at high level. However, a weekly email update in the form of newsletter can give the details and granularity that everyone needs to know about the project. Smaller team could use a simple corporate email with consistent template or format to communicate with the ecosystem. A larger team could use free web 2.0 tools such as mailchimp.com to communicate.

Knowledge tools: The product management is responsible to build and manage the inventory of product knowledge. Typical tools used are MS Sharepoint, FTP servers, Dropbox.com, salesforce.com, or fancy knowledge base tools. At a simplest form use a Dropbox.com tool create a consistent folders. Every user gets an instant notification as soon as a new version/ doc is checked-in. Every member of the team has the same version of the document irrespective of the number of revisions that it has gone through. Collateral that Product Manager uses to communicate about the product to senior management and field during the initial stages are relevant for the product development team. The one-pager executive summary of the product is a great example apart from MRD, PRD, SRS, etc. to be shared in this folder.

(source: http://www.knowledgejump.com)

Empowering tools: Product management uses many webinars to discuss and debate the research and diligence reports. Project teams could make use of such tools to conduct a 30-min project team refresh meetings to discuss about case studies, coding best practices, efficiency improvements, re-usability of code, and so on. Product management uses simple tools such as Google Alerts to capture information about competition and market. Use corporate collaboration tools such as webex, go-to-meeting, or even Google+ to empower your team with the latest and greatest in the domain, technology, or process.

Decision tools: Product management usually run multiple what if scenarios for the features, functionalities, revenue, volume, or users. This helps them take quick decision in the meetings. With emphasis on making decisions in every meeting these days, it is important that the project management uses its existing tools and run what if scenarios by modifying activities, resources, bugs, or release dates. This makes the project management to respond quickly during the meetings and in hall-way discussions to speak about the impact of changes rather than calculating them after the decision has been made.

Change management tools: The project management gets input from many people through support escalations, business escalations, management requests, and of course market changes. Product management uses simple tools to modify product backlogs and directs changes to the project management. As we know that execution is more challenging than idea generation, proper use of tools are required for project management to manage changes in requirements, schedule, or resources. Capturing the information from above tools of different teams may help the project management team to re-use or learn about the changes quickly and be agile. The bulky ERP tools that we mostly use which goes through approval from who’s who in the group may not be very effective. Combination of knowledge base, current version of the documents, and decision tools will help through navigate the changes rather than avoiding it.

(Source: http://www.ideachampions.com)

Prioritization tools: The project management team has people management, resource management, code management, technology management, and many other challenges to manage. With constantly changing business requirements, it could get overwhelming to manage changes. Using some of the prioritization methods could be helpful to manage these changes. There are many tools that product management use based on the prioritization methods used. As a first step, the project management shall get away from a To-Do list format to prioritization way of thinking, and use any of the tools that is available in the system.

The tools are only tools, and it’s the skill and attitude that would drive the business. A tool is very critical to cut a huge log of wood. The tools has to be sharp and right. At the same time, a great club in Golf will not help you achieve great results. So a combination of right attitude and a tool will help project management move away from a tactical to-do list teams to strategic teams with vision.

(Source: http://www.realministry.org)

I have written here and elsewhere -- including in academic journals with Fabrizio Ferraro and Jeff Pfeffer -- about research and theory suggesting that, when people are exposed to economic theory and assumptions, they tend to become more selfish.  This research, as with much evidence in the behavioral science, shows that exposure to ideas or even little "primes" (such as one study that simply exposed students to backpack versus a briefcase) can have surprisingly big effects on whether people are selfish or generous.  In this vein, an article in the December 2011 edition of the Academy of Management Learning & Education journal by Long Wang, Deepak Malhotra, and Keith Murnighan reports three studies that add to this troubling pile of evidence:

In the first study, students played something called "The Dictator Game," where they are given complete control over how ten dollars were distributed between themselves and a counterpart in another room.   The researchers found that students who studied economics were significantly more greedy than those who studied education, with the average economics student taking about a $1.25 more for him or herself (($7.76 vs. $6.50). 

A second study compared the attitudes of students who had taken two or fewer economics courses to those who had taken three or more classes, and found that those students who had taken more economics classes had more positive views of their own greedy behavior and of morality of greed in general.

A third study compared students who were simply exposed to short statements from economists about the virtues of self-interested behavior versus statements from economists about the negative effects of self-interest.  Then they were given a questionnaire with five statements about the benefits of greed. The researchers found that simply being exposed to these short arguments packed a wallop:  People who read about the benefits of self-interest (although randomly assigned to the condition) were more likely portray greed as good, correct, and moral.

Taken together, these studies, along with a pile of research before them, suggests the assumptions we are exposed to in life -- and those we are attracted to as well -- can have a big impact on how we view and treat others.  They don't show that economics is inherently evil, but do suggest that embracing (or just being exposed to) one of the core assumptions in the field -- that people are inherently self-interested -- can create a self-fulfilling prophecy, which can make you think and act like a more greedy person.  

Looking out for yourself is necessary in life. We all need to money, we have others we need to take care of, and striving to do great individual work can benefit those around us in many ways.  But studies like this one  are instructive.  They remind us that being around others who are greedy and selfish can cause us to be infected with the same behaviors and beliefs, that just being around money and thinking about it can lead us to be less likely to help others (and less likely to ask for help), and that when we are feeling competitive and wanting more and more it is a good time to stop ask and ourselves: Do I have enough for myself? Do I really need more?

Stories in Pivotal Tracker have been given a serious upgrade. For the most part it’s all pretty self explanatory - the functionality you’re used to is all there, just in a format that’s more intuitive, user friendly and hopefully you’ll agree, more appealing. Our advice, play with it and then come back and read the rest of this post, especially if anything is confusing.

You’re back, so let’s continue!

One of the goals of Tracker has always been to make collaboration around your story backlog as easy as possible, so that your team spends less time managing your project and more of it actually building things. We think there’s room to make that not just easier, but more enjoyable, even fun! So to that end, great usability and user experience are major themes in our backlog for 2012, starting with this story redesign.

See below for all the highlights.

New Look and Feel

Like we said, stories look different, and are hopefully a lot easier to work with now. It's a complete redesign, with a color scheme that fits better with the rest of the Tracker UI, and that's intended to make the important information in a story stand out more - such as the story title, description, comments, code commits, and file attachments.

Besides visual appeal, we’re aiming to reduce clicks - for example, when creating a new story, it only takes one click to choose a story type or point estimate value. And, you can now start, finish, deliver, or accept/reject an expanded story with one click, with the familiar buttons.

Click to Copy ID and Story URL

We heard your feedback about having to scroll down in stories to find their IDs, to copy them to your commit messages (you are using the source commit integration, right?). So, we've moved the ID to the top of stories, and made it so that you can copy the ID to the clipboard with one click (on the ID button).

The same is true for the story URL, for when you need to send someone a link to the story. Just click the link button in the top left corner, and the story's full URL will be copied to the clipboard. Note - you’ll need Flash enabled in your browser for these to work. If you don’t have Flash, you’ll see the full URL on a separate line, so you can copy it the old way.

Less commonly used actions, including delete and view history, have been moved to the “More” menu, which is where we’ll be adding some other convenience actions soon.

File Attachments on Comments

One big change in this redesign is that files are now attached to stories as part of posting a comment, rather than as a separate list. This is because files are commonly uploaded and shared in the context of an on-going conversation, and it’s so much easier to refer to a file that’s actually part of that comment (e.g. “Here’s that icon”) rather than having to say “see the file named foo.gif at the bottom of the story”.

You can still drag and drop files from your desktop to stories, and entering an actual comment when adding files is optional - just drop your files on a story and close it.

View All Images and Comment Filtering

The truth is, thumbnails of mockups attached to a story can be indistinguishable from one another. Sometimes you just need to see them all full sized, on one page. Now, with just one click of the View All Images link above the Activity section, you can.

We’ve also made it easier to find what you need in a long-winded (all of it beautifully clear and vital) comment conversation - just use the filter dropdown menu at the top right of the Activity section to show just file attachments, just source commits, or all comments without commits.

Feedback

This redesign of stories is the first step in an on-going usability overhaul. We’ve got much more coming over the course of this year, but we’d like to incorporate your feedback at every step, so please let us know what you think so far, in the comments here or by email to tracker@pivotallabs.com.

Strong SAP SDN post by Mark Chaffen on SAP RDS (Rapid Deployment Solutions) and the case of the missing Blueprint.   I’ve only started to dig in to the topic, so these are my (likely half-baked) first thoughts:

• On balance “no Blueprint” is good.  Its exclusion reinforces that a RDS implementation is of a fixed, limited scope.  There must always be some sort of scope statement, of course, and its there.  Unfortunately, “Blueprint” seems to equal “everything and the kitchen sink” in some SI’s SAP glossaries!  Wise to make a clean break in the lexicon.
• Avoid Death by Change Order.   RDS is designed to deliver only what one needs to execute — the wish list comes later.  Only fill in regulatory, statutory, or other compliance gaps during the initial implementation; otherwise make a conscious decision to remaining requirements into  backlogs that get burned down release-by-release. 
• RDS still too “new solution” oriented.  There are other ways to expand a SAP footprint… how about RDS for acquisitions, divestitures, or other growth/transformation scenarios?

Filed under: PMO Tagged: ASAP, Dennis Howlett, Mark Chaffen, RDS, SAP

The more I work within the Scrum project framework, the more I appreciate its practical and simple concepts. I am also interested in the expertise required to be a Scrum master. Like any skill you seek to master, the path may be harder than you want and take longer than you want. I am convinced [...]

10 Essential Steps to Portfolio Management By Heather Champoux Once you have a process down for defining, selecting and executing your portfolio, you are ready for the essential steps to Portfolio Management. Before we get into the actual steps, we need to make sure that the following assumptions are true: The organization’s Executive Management is onboard with the [...]

We are excited to announce a new addition to the services Galorath has to offer.  Dan Galorath (CEO and President of Galorath Incorporated) and Don Reifer (President of Reifer Consultants) have combined their collective seventy years of software development experience to offer:

Independent Risk Assessments

Risk Assessment Teams provide expert-level independent assessment services to determine root-causes of problems and recovery when faced with adversity at the enterprise, program or project level.  Dan Galorath and Don Reifer , along with the rest of the Galorath senior staff bring their extensive experience in a wide range of technical, management and costing specialties to remove subjectivity by using numbers in order to justify the needed change.  This proven methodology uncovers both risks and remedies using a variety of approaches to yield results in even the most troubled organizations and projects.

The Galorath/Reifer Risk Assessment independently determines risk in a structured and systematic manner.  Using purpose built checklists, they interact with the stakeholders to gather the facts to reveal the true issues, not the perceived issues.  Subsequent root cause analysis uses available metrics and performance data to isolate and quantify the issues from which they develop a custom action plan to fix the causes of the problem, not the symptoms.  Using this approach, they have been able steer troubled organizations and projects back on track.  Results from the Independent Risk Assessments have yielded millions in award fees, contract renewals and extensions.

Areas of Expertise

• Enterprise Management
• Systems Engineering and Architecture
• Hardware and Software Engineering
• Independent Cost and Schedule Estimation
• Metrics and Measurement
• Root Cause Discovery and Analysis

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Related posts:

1. Galorath / DCG IT Estimation For Business Value and Project Success Clinic Here are the slides from the Galorath / David Consulting...
2. Capers Jones, Gary Gack, Leon Kappleman, Dan Galorath Team Up To Improve IT From the consortium web site: Information Systems Risk Management Consortium...
3. Information Systems Risk Management Consortium: Capers Jones, Gary Gack, Leon Kappelman, Dan Galorath The consortium is the result of four of the industry’s...

Portfolio Management Process - The Process for the Process By Heather Champoux Many organizations do not have a Portfolio Management process. In order to create a process where no process exists, the following steps must be taken: Step 1: Define a Portfolio Management Organization Structure To define a Portfolio Management organization structure you can ask the following questions: Who will [...]

The Role and Significance of an Interior Design Project Manager in Commercial Construction By Kathryn Grube Abstract The question of “what value does an interior design project manager really add to a commercial construction renovation or new construction project,” in addition to the structural responsibility of the architect, has been too long misunderstood. Interior designers who work as [...]

Every project professional knows the massive effort that goes into a project... Cyndee Miller, senior editor, PM Network

Pro .NET Best Practices gets a great review from Tad Anderson in the .NET Developer’s Journal http://t.co/I0W5P4lL. 
I loved the reviewer’s lede:

I personally do not find software development an art form. It is not an unpredictable activity driven by crazy business users that come to work every day inventing a new way to operate their businesses just to savagely changing your requirements. Project teams that use changing requirements as an excuse for their dates constantly slipping and bugs being pushed to production are simply not good development teams and they are poorly managed.

Filed under: PMO Tagged: Development, Project Management

Example 3: Using a Project Manager with Iterations and Kanban and Silo’d Teams

Here, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore. The Indian testers were very smart, and unfamiliar with the product, so the developers suggested the testers test feature by feature inside the iteration.

The project manager suggested they use cumulative flow diagrams and cycle time measurements to make sure the developers were not developing “too fast” for the testers. The developers, still smarting over the loss of “their testers” were at first, peeved about this. They then realized the truth of this statement, and developed this kanban board.

You can see in this board, that four items are waiting to go into system test. Uh oh. The developers are out-producing what the testers can take. This is precisely what a kanban board can show you.

The testers aren’t stupid or slow. They are new. They cannot keep up with the developers. It’s a fact of life, not a mystery of life. The developers have to act in some way to help the testers or the entire project will fail. The reason they are working in timeboxes as well as using kanban is that they have several contractual deliverables, that management, bless their tiny little hearts, committed to. The timebox allows the team or the product owners to meet with their customers and show them their progress. (They were deciding who would meet when I last worked with the team.) The kanban board help make the progress even more transparent.

Iteration planning: The product owner and the project manager jointly work on the agile feature roadmap, and the product owner owns the roadmap responsibility for it. The product owner owns and generates the backlog. The product owner and the agile project manager present a strawman iteration backlog to the team at the start of the iteration. They have had difficulty finding iteration planning time that allows everyone to be awake and functioning, bless the senior managers’ little hearts.

Daily commitment: They do a handoff, asking each other what they completed that day and what the impediments are. If you have read Manage It!, you know I modified the three questions to “What did you complete, what are you planning to complete, what is in your way?”

Measurements: cumulative flow, average time to release a feature into the product. They are experimenting with burnup charts and impediment charts. They are still having trouble bringing the testers up to speed fast enough.

Yes, they do retrospectives at the end of each iteration. Yes, the product owners own the backlogs.

I’ll summarize in the final part, the next entry.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

Do you think team dynamics make a difference in business results?

© derby for Insights You Can Use, 2012. | Permalink | No comment | Add to del.icio.us
Post tags: management, teams

Feed enhanced by Better Feed from Ozh

Approaches to Leadership By James Grinnell Over the years there have been many different models of leadership style presented in the leadership literature. In fact, some have noted that there are as many theories of leadership as there are people studying the topic. While the literature is profuse, there is consensus in broad stroke. Daniel Goleman (2000) [...]