What went wrong - project going off track

Question

I'm not a PM. I'm a developer working on a large project with a small team at an 18 person company. The "team" is just me and the project manager. The project isn't the largest my company has ever had but it's right up there within 5-10% of the largest in both cost and complexity.

The project was already underway when I came on board. I was hired to fill the shoes of the previous developer who left just after the project kickoff. The developer I replaced had only billed about 80 hours to the project before he left. The PM had been doing requirements gathering and writing up a applications specs document along with wireframes and a giant spreadsheet with 135 functional requirements prior to me coming on board. All without a developer or even another person to consult with.

When I first came on I went to a lot of meetings and did about 50% dev work and 50% meetings, talking with the customer, trying to figure out what our datasets were, figuring out if there was documentation for ancient databases etc.

Now we are 2/3rds through are billable hours and I estimate only about 30% done on the project. This includes the rest of the development work as well as other deliverables like documentation, training, as-builts etc. Additionally the customer is a little bit upset that it has taken us as long as it has to get a functional prototype to them even though they didn't even get us access to their databases until 4 months into the project.

I'm wondering what I could or should have done earlier in the project to help the PM identify some of the risks better or refine the requirements so that we would be more on track. I had some misgivings when I first came on but the PM has been with the company for 13 years and had done all the requirements gathering already as well so I assumed that he knew what he was talking about.

Answer 1

Contrary to David, I believe that if we feel responsible for project success it is not the question of the description of our job and we could and should undertake actions which can bring us closer to project success, even if it wasn't explicitly listed on our task list.

With such approach you could:

• Deliver working prototype as soon as possible. I don't mean here a prototype covering all the functionality or even specific set of features. I mean anything that works and shows some ideas and choices you've made throughout the development. Basing on the prototype it would be way easier to discuss whether the course you've chosen is good or not, what needs to be adjusted etc.

• Deliver iteratively or continuously. Basing on client's impatience it is a safe assumption that each time you'd delivered something they would have checked it and delivered some feedback on it. This way you'd have more insight on how you're doing against client's expectations.

• Agile approach to requirements. Basing on your story I assume that requirements weren't specified in details up front. What you could do is to start with high-level requirements frame them in epic stories (or themes) or something like that and then specify more details as you go whenever you start working on new features.

• Collective decisions on priorities. Meet the client to decide what are the most important features to build. This way you will be able to deliver most value possibly soon, so even if not all the scope is delivered on time you reduce the negative impact the client would suffer.

• Reduce time spent on meetings. Actually if you are the only developer in a project 50% of your time spent on meetings seems like overkill. I mean unless the very meeting really helps you to gather more knowledge on a project I would feel perfectly safe to question the reason my need to be there.

In short, the goal would be to shorten the feedback loops between the project team (meaning you and a PM) and better understanding of priorities and value of work you do.

Answer 2

Many a client/supplier relationship has soured due to a lack of mutual understanding of the toll-gates in the project. A toll-gate in a project represents a "Thou shall not pass, until this is ready". Usually a toll-gate exists to ensure sign-off is given from necessary parties, where those sign-offs carry specific requirements. This seems to be missing in your project.

In your case, there should have been at least one well-defined toll-gate for your teams' requirements to progress, and this should have been clearly communicated to the client from the onset. "I'm sorry, but it is impossible for us to progress in a meaningful way, unless we get access to the databases. If that isn't possible now, we can look at deferring the project to a later date, or progress with the limited information we have, acknowledging an increase in total hours used, due to inefficiency", is what should have been said when reaching this toll-gate. But, that requires the toll-gates to be part of the client contract from the onset.

Any client/supplier relationship should be legally and practically condensed into "We can deliver X if you supply us with Y". If the client can't supply "Y", then the basis for the project changes, and actions to remedy that should be taken at once.

A framework like PRINCE2 is extremely heavy on toll-gates (detractors say that's ALL PRINCE2 is :)), in part because it was developed as a means to ensure satisfactory delivery of very expensive projects covering anything from construction of bridges to Healthcare IT systems. It probably is overkill to implement PRINCE2 as your PM framework, but it is definitely worth taking a look at for it's structure of toll-gates.

It's not your job to tell the PM how to do his work, and most corporate environments are sadly not friendly towards sub-ordinate friendly advice :) But if you want to help him rescue this project, you have to help him realize the following:

• He needs to go on the offensive with the client, and draw up BOTH parties' requirements for a successful delivery, citing the exact and specific consequences for each lacking requirement.

• He needs better metrics to manage his projects. 30% work done in 66% of allotted time is a catastrophe in PM. This tendency should have been caught much earlier, so actions to remedy could have been taken at a more appropriate time. The project plan should be updated with progress daily, using a maximum of 10 mins of production resources' (your) time.

• Projects don't "Just work". That sentiment equates to having a strategy relying on luck. With a bespoke PM framework based on your specific challenges and opportunities, you can make it seem like they "just work". But consistent good results, only comes from hard and smart work.

Answer 3

The answer to what you could or should have done depends on the scope of the role(s) to which you were assigned. A well developed role has a boundary description the clearly defines what is in scope and what is out of scope for a particular role. Since there were only two of you assigned to this project, likely you had multiple roles; however, none of them may have contained any scope to control schedule or cost. None of them may have had any scope related to the requirements gathering or the health of the requirements gathered. All roles can certainly escalate issues and risks observed, but whether you 'could or should have' really depends on the expectation of the role(s) you assumed.

I think some would advise that, especially with a small team like yours, a successful team has a notion of a collective win and a collective loss, so anyone member should step out of his/her role for the greater good of the team. There is truth in that; however, there are also costs and penalties with that, too. So, I prefer a well articulated role to avoid the ambiguity and the question of what you could or should have done.

Answer 4

It's always risky to start a job if the project has already started without you, especially if another person is leaving the company. This should sound an alarm and you should find out as much as possible prior to taking a job. I once made a mistake of taking on a project without physically meeting a business owner. I was 18 at the time and much has been learnt since.

135 sounds like a scary number, but I personally would look at this as an epic story with few smaller stories (each story having multiple tasks). Yes, I would probably use this in my defence to try and emphasise on how big the project is, but it's not going to solve the problem.

If project manager concentrates on requirements and doesn't promise any estimates, then it's absolutely fine. It's their job to establish requirements and its developer's job to give them estimates. However, even then I don't agree that estimating work in such a way is a good thing. I would probably look at estimating using t-shirt sizes or alternative methods.

Meetings are good, they help you understand the requirements, so I don't think that problem is in time spent on meetings.

Based on what you have said regarding deadlines and my experience as a developer, I think that your project can easily over-run by two if not three times. A lot of the time is normally taken by integration, testing and quality assurance.

I think that this is mainly PM's fault. Fact that they have been a PM for 13 years, doesn't make them a better PM. Some people achieve in six months what others have achieved in six years.