Agile is THE ONLY way to build SharePoint applications.  Pure and simple.  If you think otherwise, sorry.  You are wrong.

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.



May 1, 2007

I’ve got good news and bad news. First the good news: as a manager, having motivated employees is completely within your control. It doesn’t matter how big your budget is, how many employees you have, or how high in the corporate food chain you are. It is absolutely within your power to have motivated and enthusiastic employees.

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.

Being Available
Or, how I learned to get up off my ass and walk around a lot

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. Read the rest of this entry »

A colleague and I were talking today about project management, agile projects and I got to thinking about the point at which it is clear that a project has failed. What struck me was that I believe this point is actually much sooner than most would acknowledge. I believe there comes a point when most, if not all people on a project realize at some level that this project has failed – or will definitely fail without serious course correction. However, this point rarely leads to any serious action or course correcting – in fact most people won’t even acknowledge (publicly) that the project has reached this point.

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.