What is Project Management Anyway? Different clients have different expectations

The below is a snippet of an email I sent to resolve an issue we had with "Project Management" one of the problems was that our client thought it was one thing (based on their experiences), and we had a different notion of what "Project Management" was.

==========
<Email Snippet>
==========

Marlon,

I think some of our clients such as Westlink and Pfizer have a set idea of what Project Management is – they believe it implies “Dedicated Project Management and Oversight”. We have typically not been providing this as part of our other “Project Management” tasks in many projects, and this could lead to disappointment. In the extremely successful Maximus project, Peter McKeown from Symmetric was doing the project management by:
a. constantly planning
b. suggesting alternative options
c. talking to the clients
d. dictating our work for us
e. giving the project a high level of visibility by organising Friday demos and making sure all stakeholders were present and gave input.

This worked very well. He added real value as a Project Manager.

Project Management

I see project management as separate from creating release plans and the day-to-day meetings that developers have with clients. I don’t believe we are doing project management just by having developers send release plans and sending clarification emails. Project management is not what developers do. Consequently, I have separated this dedicated function out as an optional extra in the SSW Proposal Template. It is like an insurance policy and really needs to be done by a dedicated person that will perform the following function (as per Wikipedia):

"The planning, monitoring and control of all aspects of the project and the motivation of all those involved in it to achieve the project objectives on time and to the specified cost, quality and performance."

“Project management is quite often the province and responsibility of an individual project manager. This individual seldom participates directly in the activities that produce the end result, but rather strives to maintain the progress and productive mutual interaction of various parties in such a way that overall risk of failure is reduced.”

I believe the project manager should take on the role of and liaising with the client about problems and potential problems with the project. It is the project managers role to do the following:

1. Helping to make sure the customer is informed of budget overruns and technical issues and given the earliest possible opportunity to:
a. stop the project
b. remove tasks
c. reassign tasks to cheaper resources (e.g. China).
d. Reassign the tasks to more effective resources

This is assisted by generating Timing, ETAs and financial reports that developers don’t normally generate:
a. Financial Reporting e.g. using Microsoft Project via TFS WorkItems (based on our proposal spreadsheet) to show baseline estimates against actual figures and predict problems and deadlines.
b. Updating TimePRO projects and the project status and sending out the Project Progress report.

2. Keeping a close eye on developers/team leaders to see if there are any problems that have simpler solutions or would be better done by an expert/outside resource or using a 3rd party tool.

3. Helping to make sure that the ongoing quality of the product is good standards are enforced. E.g.
a. Identify opportunities for automated testing and unit tests.
b. Running code auditor/SQL auditor/FXCop.
c. The most effective tools are used such as using code generators for repetitive work.
d. Suggesting refactoring possibilities if there is repetitive code.

4. Helping to Removing any client-side or developer-side bottlenecks to development (e.g. following up questions that the client is not answering/developers just waiting on response or are stuck with a product bug or coding issue)

5. Helping developers to determine what should go into the current release and what should go later (scoping – ie what is in scope/out of scope)

6. Updating the scope documents (this is not done in normal projects; we typically create the document and leave it to gather dust)

2 main tasks are performed by developers which were previously classified as “Project Management” by us are:
1. “Project Administration” which includes creating releases and sending out release plans and done emails & timesheets
2. “Requirements Gathering, Client Meetings and Clarifications”

With this in mind.... I believe that dedicated project management (e.g. what I’ve been doing with Westlink) should be an optional extra in the template. I have updated the template accordingly as follows:

Updates to Template:
1. Changed “Project Management” to “Project Administration” (I think it reflects our activities more accurately for that task). I kept Project Administration (primarily Timesheets and Invoicing) at 2 hours per 40 work hours.

2. Added new task type – “Requirements Gathering, Client Meetings and Clarification.” I put this down as 4 hours per 40 work hours.

3. Added an “Optional Extra Items” Group to clearly indicate that a dedicated Project Manager is not normally used on our projects. Our normal task system (eXtreme Emails) provides basic project management capabilities.
4. Includes the “Weeks” calculation

Figure 1 - Updates to the SSW Proposal Template

Figure 2 - Added Dedicated Project Management as an optional Extra for the whole project

==========
</Email Snippet>
==========

"No Battle Plan ever survives contact with the enemy"

"No Battle Plan ever survives contact with the enemy" - Helmuth von Moltke the Elder
Recently, I was asked a question about my estimate for fixing and rewriting a property valuation system in Melbourne. I created the estimates after a 5 day specification review of their 26 applications (some of the apps had 300+ aspx pages and 200 user controls) and 20 SQL 2000 databases.

The client was concerned that one of the releases in the project was going to go 30% over the original baseline figure (of we warned the client before this happened - that is why he raised his concerns). He reasoned to me: surely after 5 days of doing the original spec review, I should have been able to give them an accurate estimate for the 6 month project.

This project has highlited some of the hazards that go with estimation - in particular - projects that deal with code written by other developers. The truth of the matter is that it is MUCH more difficult than for estimating a new application. In particular, every line of code can potentially be a shock or a nightmare.

This brings me to offer the quote "No Battle Plan ever survives contact with the enemy". In my case, this skirmish was against buggy code from a stream of developers that had "contributed" their expertise (or lack thereof) to the group of applications. Project Managers be warned! For normal projects, you take the your/the developer's estimate and double it. When you are dealing with other peoples code, I would say it is safer to triple it.

Another point that was also raised that "builders and construction companies give accurate estimates. If they can give a fixed cost for this project, then why can't SSW?"

I believe there is a fallacy amongst the general population (especially within the IT industry) that somehow builders and construction workers give accurate estimates. Nothing could be further from the truth. My boss was given an estimate by a builder for home renovations - that it would take $20K to complete the work on his house at Coogee. $200K later, they were about half way there. All the construction work I have had done (e.g. bathroom renovations) has had "unforeseen problems" and has costed more than what I expected. In fact, there a people paid in the construction industry purely to say whether work is "additional" and will cost extra or not. This is a testament to the fact that the scoping of building projects is innacurate - and often deceptively so. I wouldn't be surprised if a construction company found out a way to make a roof an additional item for a building!

The best thing that a Project Manager can do (in IT, construction or otherwise) in giving estimates is to be transparent and truthful with the client and to break down the project into as many finely grained tasks as possible. Price each component individually. This forces the estimator to examine the project with a fine-tooth comb before one line of code is written. If estimates are broken down an substantiated, then they can be more accurately analysed so we can learn from our triumphs and mistakes (aka underestimates).