Solution to scary programming/project management situation?

Question

I'm a newbie programmer in a troubling situation and wondered if anyone knew best practices for dealing with this type of project management problem.

After a rough job-search, I finally found a contract job to port an arcane system from an old OS to a new one. I was up front about having little proficiency in the languages and systems involved, but by demonstrating sharp thinking, determination and analytical skills in the test interview I got the job. A project manager even told me I was hired precisely because I had no preconceptions about the "way things should be done", and could adapt to their "way of doing things".

So, I went into the project excited, and was asked by the tech lead (the only person I directly report to and work with) to start looking through the manuals and original code for the system.

Well, I started looking... and it was vast. The manual was voluminous, the system complex, and the code running for hundreds of thousands of lines. I was immediately struck by the enormity of this task. It was clearly a system designed and built by a large company over a period of years, modified many times since. One year and only two people didn't seem nearly sufficient for the needs of the work ahead.

I asked the lead his thoughts on the original code, and surprisingly, he didn't seem to have looked at all, and didn't intend to. I asked him how he knew this task could be done within a year without even knowing what the system already does. He told me he had seen the system in operation once before, and it looked pretty basic and straightforward to him.

I know with certainty he's a highly intelligent, sharp, fast and skilled programmer, as I had the opportunity to look through and analyze code he had already written. So I thought that his confidence was somewhat reassuring, and maybe he already had this whole project figured out. So I decided to ask him what kind of design he was thinking about overall... and his answer was that we would just start coding different parts and kinda fit them together.

This immediately sent up red flags for me. So first there wasn't any thorough analysis, and now there wasn't even a design. How could we even know what parts to code, or that our parts would fit together? How can we communicate progress to stakeholders without knowing what and how much work needs to be done? I asked if there was a project schedule... and he said he had submitted one, but not to take it too seriously, he considered it a "loose guideline". He showed it to me, and apparently we were already well behind on what he had communicated to management.

Okay, I thought, I was told I was hired because I had no preconceived notions, and wouldn't be a "no, that can't be done this way" kind of person. I figured it was just a quirk of this new workplace I needed to adjust to.

Ironically, project management held a meeting a few days later, to discuss the scheduling of a big design review with major stakeholders. The project schedule that was once a "loose guideline" was now suddenly a concrete baseline, and my tech lead was visibly shaken and tried to get a later date, and now management seems suspicious and concerned.

What should a person in my position do? I had a difficult time finding work as it was, and if I do well in this job I might get future work, or at least good references if I move on. So of course I don't want to get on the bad side of the tech lead who hired me, but I've tried talking with him and he only seems interested in coding now and worrying about everything else later.

Should I air my concerns with project management and risk getting my tech lead and only co-worker on this project into trouble? Or do I just work even harder to make up for it? Or should I trust my tech lead and not worry so much, and let the cards fall where they will? I'm new to all this and facing many mixed messages, from outside and inside, and have no idea what to do. I think there's a phrase for this environment: cowboy-coding. Thanks for any help!

Edit: I'll add more details here:

• I've only been working at this company for little over a month so far, mostly reading through system manuals, analyzing code, learning as much as possible about the languages and tools we're using, etc., to get familiar with the project. Right now I basically ask my tech lead what I should work on, he thinks about it, and then sends me off to do things. For example, he might say "get familiar with such'n'such versioning software", or "find a good library we can use for network communication", etc.

Answer 1

Your accountability ends at programming. It is the PM's accountability on the success of the project within the constraints of the schedule and budget. You need to execute your tasks as assigned and use your best efforts to do the best job you can under the constraints that you have. Your responsibilities also include to escalate risks and issues in a non emotional way, to include some degree of alternatives analysis and recommendations. Hand that over the PM and wait to see if something comes of it. If nothing, which is a decision of and in itself, then continue down the path to which you are instructed.

This sounds like quite a mess and failure or degraded performance is likely, but that is out of scope for your role.

Answer 2

Project Responsibilities

There are successive layers of responsibility for any project. In general:

1. Senior management is responsible for the success (or failure) of a project. This often includes making strategic decisions about the project, making funding decisions about risk-mitigation controls, and accepting risks for the project that can't be mitigated or transferred.

2. The Project Manager is responsible for the implementation of the project management process. This usually includes referring risk-mitigation and risk-acceptance options to senior management for approval.

3. Team leads have a varying scope, depending on the project and the organization. However, in my experience a team lead is usually responsible for implementing technical solutions.

4. Team members (like you) are responsible for performing project tasks, and flagging technical or process issues that may prevent you from completing deliverables.

As you can see from this top-down list, you are not responsible for the success or failure of the project. That responsibility ultimately rests with senior management.

Provide a Professional Opinion

As an IT professional, you should certainly flag issues with the project such as:

• Unrealistic delivery dates for specific tasks.
• Missing prerequisites for your tasks.
• Flaws in the plan (if there is one), architecture, or tool-chain that prevent you from delivering specific tasks.
• Process or procedural impediments such as the lack of well-defined tasks.

The goal isn't to criticize; it's simply to provide information and visibility about project tasks to those upstream. Just document what, in your professional opinion, is required to do your job as successfully as possible within the framework provided.

Don't expend your political capital on this. Your objective isn't to redefine the project or its process; all you're doing is providing decision-making information to those who can make decisions about the project.

Once you've identified a project risk to your team lead and/or project manager, you have effectively transferred the risk to them. Remember, senior management is always responsible for accepting (or mitigating) project risk.

Early (Project) Termination

If the organizational culture is toxic, you are still likely to be "held accountable" when the project eventually fails. If that's the case, then you have the same option that senior management has: fail as early as possible.

A good project manager will recommend that a project be terminated early if it is unlikely to succeed. A good project sponsor will kill a project that is unlikely to meet organizational objectives. If failure is not an option, but failure is inevitable, then move on.

Keep in mind that the majority of IT projects fail. Being on a failing project is not necessarily a blot on your career--if it were, no one in IT would stay employed--but that doesn't mean you must stick it out if the harm to you outweighs the potential benefits.

Be professional, be sensible, and consider all your options carefully. The only person who can manage your career is you.

Answer 3

First, hat tip to @David Espina. Everything he says is true. I'm just concerned that it won't be helpful when the project crashes and burns and you're trying to shelter yourself from debris, and when you're trying to figure out how to spin this failure on the resume you're preparing for the next job.

I'd strongly endorse Mr. Espina's recommendations that you:

1. Document and escalate risks. You're in a very good place to assess the likelihood that the project will be X months late because the complexity of tasks have been underestimated. But always do #2.
2. Identify alternatives - up to and including preparing an alternate project schedule that you believe is more realistic.

In addition, I'd also update my resume and begin the job seeking process, including the small tasks that the PM has assigned (you cite "find a network communications library", etc.).

Answer 4

The project schedule that was once a "loose guideline" was now suddenly a concrete baseline, and my tech lead was visibly shaken and tried to get a later date, and now management seems suspicious and concerned.

This makes me think that there's a problem in the relationship between the PM/Management and your lead developer. It sounds like the deadline was imposed without adequate consultation with developers, which is really a failing on the part of the PM as much as anything else. That said, I'd advise the following:

Should I air my concerns with project management and risk getting my tech lead and only co-worker on this project into trouble?

If the issue isn't raised then you and/or your team will be in 'trouble' anyway because a project with a wildly unrealistic schedule is bound to fail. Better, I think, to be the person who alerts the organisation to the risks and shows critical thinking. As a PM this is what I'd want to see because, as others have pointed out, it is the PM who will ultimately be held accountable for the success of the project. However, I think you should try your best to communicate risks and concerns through your lead developer. It would almost certainly be bad for your reputation to bypass your manager and go straight to the PM/management until you have completely exhausted that avenue.

Good luck!

Answer 5

I would say that you have a responsibility to flag this issue/risk up with the PM. You don't have to blame anyone, but anyone on a project team should raise any problems as and when they are spotted.

As you're not the PM, I would say your immediate responsibility for the risk ends, but you may be needed to provide support, on the issue.

For me, it's not about blame, it's about making sure the project succeeds. As a PM, I don't mind mistakes - I mind when mistakes are covered up.

Answer 6

To reiterate the situation that you've presented:

• You are working in a contract position
• The tech lead who hired you has failed to plan out the work and has provided wildly optimistic estimates for the project to management
• Management is going to hold the team accountable for the wildly optimistic estimates

I think your bigger problem could be what happens afterwards when your contract ends. If the wheels do well and truly come off of the project (and they will if the plan continues to fail to line up with reality) it is easy enough for the technical lead to point the finger at the contract guy as the root cause for delays. As Gregg indicates, a good PM won't lay blame but your tech lead is only human and if this is a huge balls-up there is a huge temptation to deflect the consequences.

This can lead to tepid references and huge problems getting your next job.

The key will be, as David and Mark suggest, for you to document and escalate the issues and risks. Make sure that you send these through the appropriate chain of command, but cc the PM. Make sure you focus on solutions rather than the problem. Don't be afraid to voice your concerns and your ideas. This will not only help the project but will cover your rear.

Answer 7

This question is much better suited for the workplace stackexchange as mentioned above.

At this point I'd probably lead with getting out of the uncontrollable dumpster fire first, and then I'd think about how I could have tested the company during the interview process. This would a) save me time and b) spare me this nonsensical project organization in the future.

As for what to say in your resume/cv, simply either be honest about the company being far less organized and inflexible than it should have been or just don't mention it; tell your employer that this behavior is unacceptable before you get to the job; be honest about climbing out of a dumpster fire. Make sure you document how far out of scope everything was and how little work was actually done. Go ahead and include what you tried to do to fix it and how it was shut down. Then just leave. What they're asking you to do isn't work the money and overtime. Don't sell yourself short.