Manage Expectations

It's been a while since I blogged and that is for different reason. I have to be honest with you - I am not one of those addicted to Social Networks but I am trying to pick up with the progress :-)

Long story short, when anybody is talking to you about Managing Expectations they (and that including PMI) refer to Managing Customer Expectations in order to avoid the scope creep, gold plating or anything else related to major Project deliverables and performance indicators. Today I would like to talk about different expectations and those are, to my understanding, not less and sometimes even more important in your project environment as they build up a foundation stone for successes or failures to come - PROJECT TEAM EXPECTATIONS.
It carries paramount importance for Project Managers among us in order to assure the Project is on track, meeting expectations, maintaining professional and technical spirit of the team. This is becoming really challenging for large scale projects and projects heavily depending on external and non co-located resources. Software companies leveraging outsourcing and using large development centers oversees coping with those challenges on the daily basis. So how can we do that? Is there an easy and transparent way to keep the team working as a TEAM? I think there is a way and I would break it into two major components:
1. PM should walk the talk
It is really simple - no bullshit. You should always be on time to your meetings; you should have no red items on your task list; you should be the first one recommending enhancements and pointing out issues with the key project components; you should talk to the benefits other team members are bringing to the project AND you should be the first acknowledging your mistakes
2. Evangelize and leave Ground Rules
Ground Rules is one of the key Project Artifacts. It outlines major behavioral attributes of the Project Team and basically - puts the stick in the ground. Keep those simple and achievable, by the way, if you want your team to live to them and again - LEAVE THOSE YOURSELF. Ground Rules should address or relate to major Project Knowledge areas:

• Initiating (working out the charter, scope document, team's involvement in the project definition, suggestions, issues raising and so on)
• Planning (team's involvement in Project Schedule, Quality Planning, speaking up when project is going off the rails, responsibilities and accountability)
• Executing (participation in the meetings, being on time, reporting tools and processes, deployment and testing procedures, Risk Management and ownership, team dynamics, etc)
• Monitoring & Control (sprints timing, success criteria, key performance indicators)
• Closing (lessons learned, documentation, handing over procedure, etc)

You can follow a very simple set of steps to implement Ground Rules in your Project environment:
2.1 Create an area in your PMIS (for example, a list in your SharePoint site) and outline those Ground Rules
2.2 Review those periodically. It can be daily, weekly, based on the frequency of your Sprints or following any other logic you would like to work with
2.3 Review deviations of those Ground Rules during your team meetings. That might be tricky but I leave it up to you to work out the politics. With that being said, you absolutely HAVE to do it as Project Manager has to be a Leader with the capital "L". Your projects don’t really stand a chance if you are not one
2.4 Try not to introduce changes to your Ground Rules and keep them as generic as you so there are not a lot of changes as you move from one Project to another. People don't really like changes so keep their number to minimum


Here is a small example of one of the Ground Rules I am using:



















Good luck and let me know how it goes