Managing the Delivery Team

To some degree, this has been covered in a few of my other articles, but I wanted to dedicate one article specifically to managing the delivery team while acting in the role of Project Manager.

Resource Assignments

Let’s assume the team is assembled by leadership within your organization.  I’ve been in organizations where one person managed the PMO and assigned PMs to projects based on availability, geographic location, and expertise, and another managed the Business Analysts and made assignments to projects based on those same considerations. 

The technical staff is usually managed by a development manager or CIO (or both) and the technical resource assignments are made based on availability and expertise and they are often not full project timeline assignments like the PM and the BA are.  Those technical resources are assigned as needed and as determined by the project schedule and resource forecast maintained by the Project Manager.

Kickoff

Prior to the Kickoff of the project, the PM distributes all relevant project and contract information to all assigned delivery team members.  This would usually include, at a minimum:

• Statement of Work
• Original resource hours forecast/budget as finalized by Sales
• Initial project schedule as created by Sales for the customer
• Contact information for project team members on both sides
• Any relevant travel and expense requirements as mandated by the customer

Prior to Kickoff, the Project Manager and the Business Analyst are preparing heavily for the Kickoff Meeting with the customer and planning for the move into Exploration.  Frequent, adhoc communication is happening at this point to coordinate efforts and ensure that both are on the same page.

Onboarding

Once Kickoff is over, technical resources will begin being assigned – as needed – to the project and the effort of managing the delivery team resources and forecasting for their usage becomes a more important task for the Project Manager.

As new resources are engaged on the delivery team side, four things must always happen…

• Provide the relevant project/contract docs for review
• Provide recent status reports and the project schedule for review
• Provide the resource forecast for review
• Hold a formal delivery team meeting to go over current status, key project info, and answer questions

Status Quo

Once the project is fully staffed and is moving from Exploration to Design and beyond, then the effort of overseeing the work of the delivery team members should be fairly straightforward.  Maintaining proper communication and the structure that should already be set in place will help ensure that each team member is up-to-speed at any given time on project status and what is expected of them at that moment and for the upcoming weeks.  Just to review, this proper communication/structure should be in the form of:

• Weekly delivery team meetings
• Adhoc delivery team communication
• Weekly formal status meetings with the customer
• Weekly delivery of and review of the revised project schedule
• Weekly delivery of and review of the project resource/budget expenses and forecast

Summary

If all of these items are well maintained and delivered to team members in a timely fashion, then everyone will be on the same page.  The Project Manager must be well organized because usually the PM is dealing with delivery team members who have other projects to work on that are in various stages of implementation. 

Your delivery team members must always be made aware that this project is critical and that you have a solid structure in place or you’ll lose them to other activities and you’ll have more difficulty re-directing their efforts back to your project tasks.  It’s much easier to lose resources to their other critical activities on other projects than it is to reign them back in…so stay organized and fight to not lose their focus in the first place.

YouTube and KM

YouTube a KM Platform?? Are you out of your mind? thats probably the first reaction you had when you read the title of this post. Honestly? i dont blame you , i was having the same thoughts a while ago , but then as you know when an idea takes hold it takes a while to shake off.

So I asked myself this very simple question, What makes a good KM platform? and then started listing the points down one by one. This is what i’ve come up with so far ( this is a very basic list, so bear with me) .

1. Communities of Practice
2. Expertise Map
3. Great Search feature
4. Collaboration
5. Information Repositories

The whole idea behind institutionalizing KM anywhere is to for people to get to the right information at the right time. While there are hundreds of applications out there ( open source and otherwise ) the fundamental success factor for any KM initiative is to establish a self sustaining knowledge sharing culture that uses the platform to facilitate collaboration. Something YouTube has excelled at, now whether this fits your corporates definition of a KM tool is question that we shall tackle on another day.

Right, back to the question at hand. Analyzing what YouTube has to offer gives us a pretty good insight on how the knowledge ( headbanging teens and American idol wannabes ) is stored and structured. Here you can get to any information using a category tab, a great way to structure your information. Tags are another huge feature here which makes structuring and subsequently locating information a lot simpler.

Channels allow you to subscribe to your favourite information sources and receive a steady stream of information without searching for it. Finally and most importantly a Community section which gets people of similar interest together to discuss about information / interests that they have in common.

As with any self respecting KM tool the option to rate information is a must, YouTube accomplishes that with aplomb. Users are allowed to rate videos, post comments and so on enabling the “weeding” out of less desirable content.

Information like which are the most viewed videos, favourited videos and such add as a bonus to the information seeker as it gives him/ her the opportunity to feel the pulse ( so to speak ) of the community.

Statistics on how many videos were viewed /submitted by individual users can be pulled up very easily enabling ( further down the line ) a creation of an “expertise map”.

There you have it, while YouTube is not what one would call an ideal KM tool it addresses one of the most difficult issues KM practitioners face, getting people to share information. Filling the other functional gaps shouldn’t be too difficult. Now if only we can get our corporate heads to start shooting embarrassing videos of themselves.

The Statement of Work

The basis of everything…the alpha of the project.  The Statement of Work (SOW).  You review it, you study it, as the PM you dedicate yourself to it entirely for a week or so before the Kickoff Meeting and you use it as the basis for your presentation.  And then sometimes you put it away for good. 

That’s unfortunate because a good SOW of work should always be reviewed periodically throughout the engagement to ensure you’re still on track.  Since the delivery team usually isn’t part of the sales process when the SOW is finalized, then they can just trust that the customer remembers everything about the SOW while the project is in progress.  Certainly they would raise a flag if something were being performed that was not in line with the requirements of the SOW, right? 

Wrong.  As the Project Manager, you must go back to the SOW periodically to make sure that you’re not missing something critical.  On a 6-12 month project, you should be reviewing it monthly.

The Contents of the SOW

A good SOW should have the following sections of information laid out in some order:

• Overview
• Project Scope
• Objectives
• Deliverables
• Interfaces/Integrations
• Hardware/Software Requirements for the System (for IT projects)
• Scope/Change Management Processes
• Resource Requirements
• Communication Processes
• Delivery Team Responsibilities
• Customer Team Responsibilities
• High Level Project Timeline
• Contact Information

The Main Point of Reference

The Project Scope, Objectives, Deliverables, Interfaces/Integrations, and Team Responsibilities are sections that should be revisited on a regular basis.  It’s a certainty that when scope issues arise the SOW should be reviewed again, but periodic checks of the SOW may help keep scope in better check throughout the engagement. 

Certain issues like who is responsible for cleansing current customer data prior to load is usually laid out in the SOW and those are critical efforts that occur later in the project prior to testing and implementation.  Understanding those requirements and ensuring that the associated tasks are properly built into the schedule and assigned to the right team helps in two ways…

• Ensures that the proper skilled resources are available when they are needed
• Ensures that the proper window of effort is blocked off in the project schedule for those critical one-time tasks

I always make it a point to review the SOW in detail during the Kickoff Meeting and make it a major part of my presentation to the customer during that phase.  It’s kind of a “speak now or forever hold your peace” moment in the project…but not really.  Everything can be discussed…and most things are somewhat negotiable – especially if more money can be involved.  But a thorough review of the SOW to kick things off followed by period checks during status meetings and as issues arise throughout the engagement will help stave off potential project delays and budget hits if dealt with directly and swiftly and in accordance with the SOW.

Summary

The SOW is basically the project ‘bible’ and should be treated as such.  The original pricing is based on it.  It was thoroughly reviewed during the Kickoff Phase.  The Exploration Phase started with the SOW as a baseline.  Always remember that the SOW is where the project started and it also is where it should end up (with change orders acting basically as addendum’s to the SOW).  Keep the SOW in proper perspective and in front of both project teams when questions arise and things – including change orders and scope issues – should run more smoothly.

Is the Customer Your Friend?

This is an interesting question. Is the customer your friend? Dictionary.com defines a friend as follows:

• A person attached to another by feelings of affection or personal regard
• A person who gives assistance; patron; supporter
• A person who is on good terms with another; a person who is not hostile

If you consider those definitions, then for the most part, your customer is your friend. But let’s look deeper.

The Relationship

What type of relationship do you usually have with your customers? Look at your most successful projects. Did you develop close, friendly relationships with your customers or anyone on the customer team?

I believe good relations are in order during and after a project. You can even become best friends after the project engagement, but during the project it should remain somewhat less familiar and definitely all business. For the same reason I’m not a fan of being close friends with a “boss” or “manager”, I’m also not a fan of being close friends with your customer.

There will always be a time – on every project – when tough decisions need to be made. Where you must be above reproach and able to ensure that you – as the Project Manager and point person – are making the best possible decisions for your organization, your delivery team personnel and the good of the project. Your relationship with the customer or anyone on the customer team should never come into question. And it certainly should never affect your professional or personal integrity or the perception of how you conduct your business.

The Premise

This is an odd article, I know…but one I felt I should write. I’ve seen too many times when the relationships between one or more delivery team members and one or more customer team members becomes too familiar and decision-making suffers. This can especially happen in war-room settings when the two teams are thrown together in close proximity to work for several days or even several weeks to get through a critical phase or issue on a project.

The progress being made and the camaraderie can be a good thing – as long as it is enjoyed in moderation. Keep it professional – the dinners, the drinking, the communications. Sometimes too much can be said and in the long run it can cause problems on the implementation and can even invite legal issues if things go south later.

Keep it Professional

This is a view from a different angle on the project engagement and the relationships among the team members, but it is important to consider. When you’re working with the customer, you’re still representing your company (or professionally yourself if you’re acting independently).

Keep in mind that no one is immune to legal action and over-familiarity with the company paying you is not usually a good thing. Keep the discussions as professional as possible, avoid inside information and especially gossip, and plan for the future of the project and your professional future when considering what information and topics to discuss with your customer.

The Responsibility of Defining Requirements

I seriously think this topic could be never-ending.  If every project was fully defined down to the last detail, there would never be a misunderstanding with a customer, no scope creep (unless the customer’s business changed in mid-project), few budget overruns (at least less likely), and certainly much less finger-pointing. 

As the Project Manager, the responsibility would not really be less or easier, but heading into a project knowing that there would be no question marks sure would make me sleep better at night.

The Customer’s Responsibility

It is my belief that every customer should go into each engagement with their own business processes well mapped out.  They also should have a solid list of requirements documented to hand over to the delivery organization.  Those requirements are the basis of the Statement of Work (SOW) and then the SOW serves as the springboard to further requirements definition and refinement and gap analysis during the Exploration Phase before heading into the Design Phase.

It is definitely in customer’s best interest to work internally prior to Kickoff with their subject matter experts (SMEs) to do their best job possible defining thorough business processes and requirements for the project.  With this task accomplished prior to Kickoff, then the delivery team will be well-informed heading into the project of what the customer truly wants from the system.  This will serve several purposes over the course of the engagement:

• Less scope creep
• Fewer change orders
• Minimized risk
• Less chance for budge overruns
• Minimimal impacts to the project timeline

The Delivery Team’s Responsibility

It’s worth noting that the delivery team – and the sales team for the delivery organization – definitely have specific responsibilities here.  The sales team must make it very clear to the customer that there is an expectation for the customer to gather with their SMEs and define business processes and requirements on at least a high level prior to the actual start of the engagement.  Don’t assume that all customers know and understand the process.  Assuming anything during the sales process can lead to unexpected delays and cost increases during implementation when poorly defined requirements and business processes are identified in greater detail and found to be in conflict with the current build of the solution.

Likewise, the delivery team has responsibility.  That responsibility includes both educating the customer on requirements definition and helping them through that process during the Exploration Phase.

On some projects, the entire requirements definition process will be and should be a joint effort between the delivery team and the customer.  However, on large implementations lasting 6 months and longer, the customer needs to head into the engagement with a good handle on their own requirements for the effort so that the project hours on both sides can be used more efficiently to drill down to more detailed requirements as both sides prepare for the Design Phase.

Summary

I fully believe that it remains the delivery organization’s responsibility – and specifically the Project Manager’s responsibility – to ensure the success of the engagement by managing the processes, the communication, and the information flow that takes place as the engagement progresses.  However, the customer shares a great deal in preparing for that success by knowing what they want and heading into the engagement with the right information about how their organization runs now and how it should run after the implementation.

Proper attention paid to requirements during pre-kickoff planning by the customer will allow for both teams to work together to drill down deeper into the requirements and ensure that the necessary detail is in place during the Design and Development Phases as the Functional Requirements Document (FDD) and the Technical Design Document (TDD) are being constructed and developed against.