One cannot place enough emphasis on the value of setting proper roles and expectations for ANY project and the importance becomes even more glarring when there are multiple business units, vendors and mini-projects all trying to get to the same goal.

Here are a few quick must dos at project kickoff regarding this topic.  There are many others – but these 5 things should be at the top of your list when kicking off a project – and MAKE SURE you invite all known project participants to the kickoff meeting!!!

1. Clearly define and document all team member roles.  Don’t just break it down by groups, but be very clear and concise toward each individuals specific role.
2. Clearly define and document any and all owners of the various aspects of the project.  For instance, if there is a business decision conflict that comes about, who makes this decision?  The more you can dwindle this down toward one person, the better.  Decision by committee is very challenging (though sometimes it cannot be avoided), so t should be avoided if at all possible.
3. Cleary define and document the communication plan.  Who gets what when in the form of communication has to be agreed upon and the plan should be distributed to all team members by the project manager(s).
4. Define who will resolve resource conflicts by dictating priority.  Is this the PM?  Is it a business manager?  Does there need to be a meeting if one comes up?  There will be plenty of priority conflicts – they all need to be quickly resolved and having a sound game plan ready to execute when needed.
5. Clearly define and document the status update process.  Is it via email or meeting?  What is the frequency?  Who participates?   Is there a standard agenda?  These are all things you should think about.

Knowing the answers to these questions and having sound documentation distributed out to the project team will save plenty of heartache down the road.

Happy kickoff!

Matt

I spent a couple years with a company that made some unbelievable strides in the time I was there.  When I first started, there were so many gaps in their processes that caused unneeded stress, unbelievable work hours, the highest customer dis-satisfaction I have ever witnessed and tension between team members.  I thought it would be interesting to post a paper I wrote, shortly after starting with this company since it has so much relavence to any IT Software Service Provider.  I’m happy to say that through everyone’s dedication, the hiring of an additional leader and a willingness to service their customers – much (if not all) of this is in full scale motion – and working very well. 

Below is really a combination of an initial gap analysis for the company processes, detail on previous process experience and general documentation to help guide change in 5 key areas:  Requirements, Testing, Estimation, Accountability and Project Management.

Requirements:  Any long-term successful software project must have clearly defined, well thought out, group decided upon, pre-work requirements.  This is a long drawn out process that may require long, somewhat boring meetings with the requestor(s), the developer(s), the PM, the testers etc – but it is key to saving time (=money) and reducing (in some cases eliminating) problems after the fact.  The cost to re-do things increases exponentially, hence the 1:10:100 rule or the waterfall effect.  It can be painful to implement full scale requirements documentation processes, but in the long run it will be extremely beneficial for the overall health of the business unit and technical teams alike and also helps more accurately meet the users needs at first crack.  Not to mention anyone that already has certain expectations made up in their mind, will be given a forum to get it out on the table before it’s too late.

Notes about effects and alternatives along the way can help pave the path for when a similar circumstance is met.  This may require some additional tests (business tests) so we know the process is running smoothly.  Lessons learned meetings, water cooler talk, whatever, however it gets to the PM or another appropriate party to document the missteps for future reference is extremely handy.  The key is for requirements, all changes (hopefully through change control) and outcomes to be documented and learned from, good and bad, from both the business and technical units.  As long as there is something being done that never has been done, there are probably going to be problems with the requirements, but they can be minimized greatly using the right steps.

Testing:  Testing should be not only for items that have come through the queue in change, but also complete regression testing for those areas that are effected by the change….for instance, a change in automatic payments somewhere in the workflow could also effect any of the payment logic processes downstream OR it could effect something upstream that will eventually hit that same point in the logic path.  Good communication (going back to requirements) upfront with the development team, testing staff and the business unit can help us determine not only WHAT needs to be tested, but also get a really good feel for the testing effort – which needs to be included in the total project completion estimates.

Essentially, as part of the requirements gathering, or at least as a follow up, we should have documented estimates for not only the development effort (i.e. – 20 hours to do “x”) but also for the testing effort (typically testing effort is estimated at exactly half that of the development effort, for cushion).  This is obviously flexible, but starting here is something close to industry standard.

Estimation:  Again, it all ties back to the requirements piece, but out of gathering those requirements, the PM should be able to have a really good feel for the total effort, on all fronts.  At the very least, it is a good precursor to successful, on time and on budget software project work.  We can start our estimates with “educated-guess” effort and learn from those and adjust accordingly.  This is part of a painful process, because at first, it may take more time to get things done, out the door, etc……but with near imminent certainty in the long run, things will get done more quickly and at a lower cost in both dollars and resources.  Having a good feel for what the total effort is going to be, is a crucial part to the success of any project and really shouldn’t be ignored or skipped over.

Accountability:  Some form of tracking of the efforts, even if manual, would be helpful in gauging how we are doing as a group, how time is actually being spent (for future reference) and, not to mention, show the business’ worth – which is no doubt huge to the holding company…..but how fantastic would it be to have documented proof that we are offering a significant return on investment?  There are many systems out there for time tracking, effort tracking, etc….but they can get very costly.  It would be ideal to find a way to track the total effort, tally the numbers and have this as a reporting tool……this could be something the PM could track, or otherwise designated. 

Project Management:  Ultimately, this piece will take care of itself with simple proactive organization, action and re-action.  Needed are requirements outlined and accurate estimations to be able to set goals.  The project should always be something that is finite.  It needs to have a clear start and a clear finish…….which doesn’t necessarily mean there needs to be tons of extra documentation and extra “busy work” for anyone, but it does mean that everyone should be on board with the expectations as to when something starts and when it ends.  This could be a simple patch or change to the system or something HUGE that takes weeks/months.  There are going to be uncertainties, risks, delays, problems and issues that will all need some action and attention….that’s a given, though we’ll hope they are always very small and non-threatening…..but given that, we need to control the things we can for “best success”.

OK, so I’m sure it’s not the most shocking headline you’ve ever read….but I have to talk about this.  Looking back on my experience in the classroom (which was a total accident in the first place) I am astounded at the similarities between it (teaching) and project management.  Actually, if I take it one step further, I’m just generally amazed at how much I LEARNED being a teacher.  Perhaps it was my youth.  Perhaps it was my open mindedness to the students.  Perhaps it was just how much I actually enjoyed it.  I really can’t put my finger on it…..but I’ll say this with 100% confidence:  I learned more about myself, my abilities (or lack there of) and the need to find the right people to lean on to get things done than in any other position I’ve held.  It propelled my ability to organize a group of people to complete a task to extraordinary heights and it sent my confidence to lead soaring to new levels.  To coordinate the efforts of a large group of people to make something real is what I truly enjoy and I had no idea until I was tossed in front of a room of 23 people for the first time.

If I step back a bit to discuss the “accident” comment in the first paragraph…..

In 2001, I had been working for an IT company in Omaha, NE that had some real potential.  I worked in system and network design and I was learning a ton from my peers.  The owner was extremely cool (I looked up to him) and I thought life was grand.  Turns out – the owner was drinking more than selling and things took a turn for the worst…..I was out of a job.  I spent the next couple of months being very selective with my interviews and trying to find “THEE” job.  It never panned out the way I thought it would.

One night, a good friend I had made at another company (oh by the way – keep your eyes out for my post about networking, I’m gonna tell you how I made thousands in college….just by making friends….once it’s done I’ll post the link here)…..OK – I digressed.

Like I said, one night a good friend of mine that I hadn’t spoken to in quite some time gave me a call.  He had no idea I was out of work.  It was near the holidays and a teacher at his college had walked out, for personal reasons I’m not privy too, but it left a class of 23 without an instructor.  It was a class on networking (CompTia’s Net+ to be exact).  He asked me if I would be interested at all and felt that I would be a good fit.  I’m traditionally outgoing and don’t mind speaking in front of a group…..but teaching?  First – I thought the money would be (enter word here) and secondly I had ZERO experience.  Who the H-E-double hockey sticks is going to hire me to teach…at 23…with NO experience????  Well….it’s good to have friends.  I interviewed for about 20 minutes and was hired on the spot from my friend’s recommendation by the dean of the college.  It was a Friday afternoon and I had until Monday to have the curriculum down and ready to teach.

I spent that afternoon at the school gathering all the materials I could for the class.  Of course the book, the former teacher’s notes, handouts, tests that had already been taken, etc.  I had no idea what I was going to do come Monday, but I leaned on my friend.  He told me to just be myself, give a good introduction, let the class know that regardless of how disappointing the situation is that we’re going to make the best of it.  All of a sudden – I felt about 1000 lbs off my shoulders.  This I could do.  For some reason I pictured this image of myself with a oddly trimmed beard and perfectly round glasses acting all intellectual…..NOT ME (well not really anyway).

I decided over the weekend that I wasn’t going to teach at all on the first day.  I was going to get to know everyone, what they liked to do, what their strengths were, where they grew up, etc, etc.  Well, the first day came and went and overall – I think it went pretty well.  I could sense some disappointment and uncomfortableness with me – but that was natural.  Heck – I felt the same way.

After the first week, I talked with the director of the technology dept about the approach I can take to teaching.  I explained to him that I don’t have any traditional teaching experience and that I only know how to learn by “doing” and that I thought it would be best for the class if I could take that approach.  It turns out – I could pretty much change the curriculum as I wanted.  So I did.

I developed a methodology that I think worked very well….and well….it was all I knew how to do.  I lectured, of course, when it made sense – but it was as much of an interactive session as possible.  For the most part, I divvied out responsibilities to the class putting each person or persons in control of various roles to get the “project” done.  I would assign the system admin role to someone.  The PC tech role to someone.  The support role to someone.  The analyst role to someone and so one.  I had no idea at the time, but it was actually my first experience as a PM.  It worked…..astonishingly well.  People were learning so much by using hands on techniques rather than just reading and taking tests.  I honestly was amazed at what folks were learning and I was learning with them!  Yes – I created assignments that I didn’t even know how to do.  I served in a consultant role to the group, bringing in experiences and pointing them in the right direction.  It was pretty cool – and as it turned out, sprouted a career change.