Oh… you wanted an explanation?  Okay – here you go.

I could bore you with a bunch of background on Agile and what’s good about it, what the process is, what the core concepts are, etc.  But I won’t.  If I did that we would just go back and forth forever on the benefits/shortcomings of Agile development.  Instead I’ll get right to the point.

You do not know enough about SharePoint to fully spec a solution end-to-end.

Let me repeat that.  YOU (yes you), DO NOT know enough about SharePoint.  I know you think you do.  I know you think you know how everything works, how everything fits together, but you don’t.  And you know what?  Nobody does.

There you go.  Any application you want to build that has any level of complexity just cannot be fully designed up front.  There are too many unknowns at every level in the product.  Too many assumptions need to be made about what should work.  And we all know that there are dozens of unanticipated gotchas waiting around every turn.

SharePoint 2007 is a huge product.  It has a ton of little nooks and crannys each providing great functionality, but also hiding pure WTF, “why did they do it that way”, suprises.  SharePoint is just too big and too new for anybody to know it intimately enough to fully define a solution end-to-end without actually doing some trial and error implementation.  So if you’re doing trial and error implementation anyway, why not include the client and make them short iterations?

Okay – a few more quick benefits to this approach:

1. Don’t have to spend time documenting out of the box functionality that you don’t have control over anyway
2. Wireframes and UI designs are less critical because you can “design” on the fly using the out of the box UI – then identify the gaps where additional design elements or controls are needed
3. End up with less code/customization because once users see it out of the box, they quickly reach a “good enough” point.  You can focus your customizations where where adds real value.
4. The very nature of letting the user touch and feel the solution will change their requirements.  They will realize that certain things are less important than they thought while others are more important.  This is true with any application development but the fact that you can do so much out of the box in SharePoint means you can get to this point very very quickly.

So there you go.  Good luck.  We have a tough fight ahead of us convincing people that SharePoint is different enough to warrant throwing old waterfall methodologies away and trying something new.

Now the bad news: having motivated employees is your responsibility – yours and yours alone. It’s not the responsibility of the HR department or some disconnected “Chief Culture Officer”. It is your responsibility. And it gets worse – if you want to motivate your employees, you have to mean it.

So, before you read any further you need to ask yourself a question: do you feel motivated? Do you want to motivate your employees? Do you want to motivate your employees because you want them to feel the same commitment and passion you do? Or because you want to squeeze a few more hours out of their already long work day?

Motivation is all about communication and vision. It’s about transferring your own motivation and drive to your employees. If you don’t believe in the vision, then no amount of “employee retreats” or “team building exercises” are going to make a difference.

So again, ask yourself if you really feel it. If you don’t, it might be a good idea to step aside so someone who is truly motivated can take the reins. On the other hand, if you are motivated and are looking for some tools to help you transfer that motivation to your team, please keep reading.

Still here? Okay well either you’re lying to yourself, you’re really bored and are reading anyway, or you really do feel enthusiastic and want to pass some of that along. Hopefully it’s the latter, but I’m not going to be picky.

I’ve broken this article into four parts:

1. Being Available
2. Empathize, to a point
3. Commitments
4. General conduct

Part 1 (Being Available) is ready to go now. The other 3 parts will be posted as my time allows.

As I said up front, motivation has a lot to do with transferring your enthusiasm to your employees. But in order to do this effectively you have to be genuine about it. If you aren’t feeling it, you’ll end up doing more harm than good. Employees only need a few “fake” ra ra sessions to start seeing everything you do in that light. So the best thing to do if you aren’t feeling the enthusiasm is to do nothing. Doing nothing is much better than doing something in this case because that something is likely to cause damage that is very difficult to undo.

On the other hand, when you really are feeling it, you want to share it right then and there. When an employee has done great work, praise that work immediately. When the company just landed an awesome new opportunity, tell everyone right then and there.

I’ve always felt that transferring your enthusiasm is much more effective when done in a casual and spontaneous way. When employees see you being enthusiastic in non-orchestrated settings, it comes across as much more genuine. This is why I says be available – walk around a lot – maximize your in person time with your employees. The more time you have with them, the more opportunities you will have to communicate new ideas, be exposed to their great work, and generally check in on how they are doing.

This is such a small and easy thing it’s amazing to me how many people don’t do it. They think that managing people is sitting at their desk, reviewing reports, answering emails, and conducting one on ones. Why should you have to wait two weeks to have your appointed one on one when you can walk over to their desk and do it right now?

A few words on employee praise. Employees want to feel good about the work they are doing. When they feel like they are doing great work, they want to be recognized for that. However, many employees aren’t necessarily into the whole self-promotion thing and thus feel somewhat uncomfortable tooting their own horn. By walking around a lot and being generally available you put yourself in a position to see their great work first hand.

The most effective praise is tied directly to an individual accomplishment. Being able to walk up to someone and say “hey – what you’re doing right now is great” is so much more effective than a disconnected “you’re doing a great job here” comment. I think this is partially because the latter doesn’t really have any insight into what the employee is doing. It fosters comments and thoughts like “he doesn’t really know what I do” or “she has no idea how challenging this is”. When you praise an employee immediately for a specific accomplishment you have witnessed, it tells the employee you know exactly what they’re doing, have seen the great work, and think it’s great. It’s a much more genuine form of praise. And being genuine is what it’s all about.

Another extremely valuable insight you gain from walking around and being available is the pulse of the organization. Are people heads down working with little or no communication? Not necessarily a healthy organization. Are they whispering in groups? Lookout for turnover. Are they happy and joking around but generally focused? Hooray for you! This is the kind of insight that is impossible to discern from reports, company meetings, etc. These insights require your intuition as a manager who knows his or her organization and knows when it’s running smooth on all 8 cylinders.

There is some risk here and you need to be aware of it. Employees should not see your presence as a signal to get back to work. “Uh oh, here comes the boss. If he sees us talking he’s gonna be pissed!” To a certain extent there will always be an element of that – it’s inevitable. But there are some things you can do to minimize this.

1. Don’t publicly call people out when you see behavior you think should be addressed. Of course if you see something that is clearly wrong or unethical you must address it immediately. But for minor things like surfing the web, joking around the water cooler with colleagues, etc, let it slide. If you pick up a pattern and think it needs to be addressed, talk to people in private later. It is important to disassociate any criticism from your presence in the office. It is also important to avoid giving employees who are performing well the impression that they’re in the same boat with the slackers.
2. Join in the conversation. Not all manager/employee conversation needs to be about work. If you join in a non-work related conversation, or better yet initiate one yourself, you come off as non-threatening.

Two quick pointes about item number two above. Like everything else we’ve talked about you must be genuine. Don’t try to be something you’re not. If you try and join in on a conversation that you have absolutely no background in, you’re going to come across phony. We’ve all seen The Office and it’s painful. You don’t want to be Steve Carrell in your own office. This can be tough when there is a significant age difference between you and your employees (oh please no stories about how it was in your day).

The second point is this. Keep it short and sweet. This is both for your sake and your employees. On your hand, you don’t want to foster a culture that regularly takes one hour digressions into the geo-political state of various 3rd world countries and the parallels between that and modern capitalist trends that will eventually result in our ultimate and utter demise.

And for your employees, remember that you are still their manager and to a certain extent they will feel compelled to participate with you in these discussions. They will feel obligated to laugh at your jokes, agree with your opinions, and continue the conversation until you indicate that it’s finished. From their point of view, there’s nothing worse than to have what used to be an interesting conversation crushed by some old guy who doesn’t “get it”, and then have that drag on for 20 agonizing minutes of hell. So like many things, this is a balancing act. Participate enough so as to be non-threatening, but don’t go overboard.

The funny thing about this is that too little of this will make people get back to work when they see you coming because they think you don’t want them socializing. Too much will have the same effect but because they want to avoid a 30 minute conversation about something they don’t care about .

So in summary, making yourself regularly and informally available to your employees is an extremely powerful tool for motivation. By maximizing your face time with your employees you ensure that you will have as many opportunities as possible to genuinely transfer your own enthusiasm. You put yourself in a position to regularly and naturally praise them for their accomplishments, and you gain valuable insights into the overall temperament of your organization.

And all of this can be achieved by simply getting up off your ass, putting away those damn reports, and walking around saying “how’s it going?”

Now, I am certainly not above this phenomenon. In fact, it’s one of my weakest traits as a project manager. When I look back at some of the projects I’ve been involved in, I can identify the point at which it became clear that we were not on a path to success. This is the point at which I begin to wake up in the middle of the night plagued by the endless list of to-dos and the bewildering feeling that we’re no where near where we need to be (or where we say we are). However, rarely did I take the steps necessary to correct this situation. Instead, I found myself doing what a lot of managers do in these situations:

• Cutting Corners – every time a new situation we hadn’t thought of rears it’s ugly head, we come up with a hack (i mean workaround) to eliminate it. We know that it isn’t really in the best interest of the project, but if we do it this way we don’t have to miss a deadline. And of course we can always fix it on the next phase (right – when was the last time you had the time on a project to go back and fix a hack from the previous phase??).
• Calling Meetings – what do we do if we feel like a project is spiraling out of control?? Call lots of meetings of course. Require everyone involved to provide you with a full status report and a list of all open issues and roadblocks. These meetings become an opportunity for the project manager to start distributing responsibility for failure to the various members of the team. They become a way to passively distribute blame and offload personal responsibility on others. Rarely are these meetings constructive, positive experiences where everyone works together in the spirit of getting things on track. Instead they become a forum for the managers to issue broad statements and ultimatums while immediately silencing anyone who voices an alternate viewpoint or tries to interject reality into the conversation.
• Issuing Ultimatums – the first time you hear “no matter what happens, we WILL ship on time” you know you’re in trouble. In fact, I would suggest that as soon as one feels the need to issue an ultimatum like that, the project has failed. Hearing statements like this tell you two things: 1) the person issuing the statement knows that the goals are unrealistic and 2) he doesn’t give a damn and would rather burn out the team than deal with reality.
• Adding People – this is probably the worst thing you can do. The only thing worse for productivity than bringing in a bunch of new people with no context and no background in the project is to ask for more frequent status reports. Adding people just means that all your current team members will have to spend half their time training the new people and the other half of their time correcting their mistakes.

The crazy thing about these activities is that they are a clear signal to everyone on the project team that the project is doomed. These actions effectively broadcast downward the trouble the project is in. This is the point (I believe) at which it becomes clear that the project has failed. Everyone knows it. Everyone feels it and while they still say “yes – it’ll be tough but i think we can do it”, what they are thinking is “there’s no way in hell”.

So why then do we not deal with these situations? Why do we not deal with the reality that the project is simply too big or too complex or too ambitious? For me, the answers are insecurity and unrealistic optimism.

Failure is a bad word. A failure in your career is a bad thing. Nobody puts failures on their resume. Ironically, failures are what we learn the most from because they force us to really examine the situation so we can avoid it in the future. Maybe even more ironic is the fact that acknowledging failure early enough might lead to eventual success. I would submit that if all project managers publicly, loudly, and clearly stated that a project was going to fail at the point at which they realized this was the case, that 50% of those projects would go on to be successful. Another 40% would be canceled and end up saving the organization a ton of money. However, the personal and professional security required to do something like that is something that most people lack. We’re afraid we’ll be seen as a skeptic – not a team player – a nay sayer. We’re afraid our superiors will say “well if you don’t think you can do it I’ll find someone who does”. And the fact is – there are plenty of eager individuals waiting to prove themselves who will say yes after you’ve said no.

So what do we do? Do we adjust the plan for success? Do we really dig into the details to see what we can possibly do to succeed? Nope. We hope. In essence, all we do is hope. We hope that the ultimatum we gave at the status meeting earlier will be taken seriously. We hope that the extra team members will be able to get up to speed quick enough to provide value. We hope that the corners we are cutting won’t impact usability, cause data corruption, etc. We hope that our superiors won’t drill into too much detail when we tell them the project is “tight, but on track”.

The fact of the matter is that many projects simply become more complex once they get underway. New requirements surface, assumptions are proved incorrect, and a whole host of other issues seem to crop up. This is bound to happen on any project. As project managers we try to plan for this, but sometimes it’s simply more than the schedule can bear. Unless we are secure enough to be vocal about the impact these issues have, and unless our superiors are able to really hear what we are saying without seeing it as descent and lack of commitment, we can’t be successful.

So I guess in the end my point is this. When you hear an IT manager or exec bemoan the fact that they spent $1.5M and in the end got nothing for it, I believe that by the time they had spent $500,000 it was clear to everyone on that team that no matter how much money they spent they were doomed for failure. The tragedy is not the failed project, but the fact that it took another $1,000,000 before anyone had the guts to say anything about it.