PHP Project Management

Whether we like it or not, unless we are doing a hobby project just for our own amusement, even the most technical among us are really just project managers who can code. And, as a project manager, we can experience the heartbreak of project failure.

There are many ways in which a project can fail. It can fail because deadlines are not met, budgets are exceeded, the results are not what was required, etc. But, it can also fail emotionally; the project may have succeeded but people’s expectations aren’t met and there’s no sense of satisfaction or a “job well done.”

So what can you do as a technical project manager to minimize your chances of adding “leader of a failed project” to your resume? The answer is: pretty much what non-technical project leaders do.

Manage Expectations

It’s fine to think that reality is important, but everyone in the business world knows that what people think happened is always more important than what really happened, and the same is true for projects. Even some of the most successful projects can suffer from a failure of expectations that forever eclipses the good work that was done and the benefits received. And if the failure of expectations is serious enough, it can even undermine and derail other projects that were doing okay. So how do you manage expectations?

First, make sure everyone is very clear on what the project is going to do, what the benefits will be, what is going to be required from the users, what resources are needed to support it, what other projects it might depend on, and what it is going to do. I know I listed that last point twice, but it’s really important! Many times users hear what they want to hear, and it can take more than a memo or a quick conversation to set this straight.

Be especially careful about what upper management says about the project, both right out of the gate as well as later on as the project progresses, and move quickly to correct any false claims that are made before they can become accepted wisdom and “part of the project scope right from the start.”

At the same time, move just as quickly and politely to deal with any negative talk you hear about the project. The idea is not to squelch mutinous talk (although getting a list of names is not a bad idea, you know, for later) but rather to find out if it’s a misunderstanding, mis-statement of the facts, or if this is something that could turn into a problem later and should be dealt with promptly, either by modifying the project specs or taking another look at the basic assumptions.

Don’t Be Traditional, Be Iterative

In a traditional, waterfall type project, you develop a project plan that starts at the beginning and goes on to the end and stops with an overall time and dollars estimate. Don’t do that. Instead, use an iterative, agile project model where each step ends with a readily testable, highly visible product that people can measure their expectations against.

Despite the similarities, technical projects are not like building a bridge. The main unknowns for bridge building are the soil characteristics you’re putting its footings into. Once that is assessed, much of the uncertainty is taken out. Technical projects may not have more variables, but they’re spread out through the life of the project and you never really get to the point, until you’re done (maybe), where all of those variables are known. Waterfall is based on the fact that unknowns will be assessed and compensated for going it. For various reasons, tech projects don’t seem to work that way and so waterfall is a poor model.

The main problem with waterfall, however, is that it works to focus people on some nearly final ‘test’ stage. It’s not designed to support situations where testing starts almost on day one. As a result, problems, even major problems, won’t be identified until the project is pretty much complete.

Agile, on the other hand, is all about iteration: work for two weeks, produce something that is real and have users test it, then repeat. There’s no Power Point presentations or marathon team meetings, just something people can log into and play around with. That’s what gets their attention, don’t you know.

While you’re doing Agile, I would also suggest doing Scrum. They don’t have to be done together but I think it’s a good idea. You know what people like? They like things that are short; it starts, it happens, it’s over. Bang. That is the essence of Scrum – frequent, very short, no time to get comfy or to beg off, project team meetings where we talk turkey and we talk fast. It prevents anyone from forgetting about the project and what it’s doing, and doesn’t take up a ridiculous amount of time from their day.

And what does all of this do for you? Agile and Scrum allows you much more visibility into how you are doing on the overall project estimate. With serious user testing going on regularly, you get an early heads up on things that might have to be added to the app and things that can be pulled out. If there are major problems, you can begin the redesign very early in the process. This makes you proactive, which is sort of like having nice hair; it always pays dividends and puts the project in a positive light.

The Evils of Scope Creep

More projects are doomed by scope creep than anything else. Scope creep causes projects to be late, over budget, and failing to meet to the subjective expectations of the guest audience. So, don’t let it happen. Like enjoying time with your in-laws though, I know it’s easier said than done.

In its most common form, scope creep occurs when someone brings up a point and introduces it with the words “but this was the way we wanted it from the beginning.” And they’re probably honest; they may have genuinely thought that feature X was going to perform function Y and that in fact was the main reason for the project’s existence in the first place. And so, because it was suppose to be in the application from the start, you add it in. Sometimes the impact of this is inconsequential, but most of the time it isn’t. And this can happen not just once in a project’s lifecycle, but it may happen over and over again. So what do you do?

First, whatever else, you have to be diplomatic. You may feel like leaping across the table and grabbing someone’s throat, you have to remain calm and keep the balance of power on your side. Go back to your initial project statement and show that the request was never discussed, much less identified as an integral part of the application (that’s where having a very clear and detailed statement of the project is critical).

Second, to limit the number of times scope creep comes up, you should make sure that your users are doing a good job at their iteration testing. Scope creep is most damaging when it occurs later in development where a lot of retrofitting which is more or less invisible to the user has to be done. Iterative testing, rather than just talking about how the project is going, is a much better way to ground the user in just exactly what the system does.

Ultimately, the problem is two-fold. First, you may not have been detailed or specific enough in terms of what the app will and will not do; both sides need to be spelled out. Second, you need to keep in mind that your users probably are not paying 100% attention when you talk or when they read something you have written (even when they are in a meeting for the specific purpose of hammering out what the app should do). Don’t expect that because you have explicitly spelled things out that people will know. A good technique is to lay out your plan and then have them tell you what they think the system will do and what they can expect from it. Record the session – you can use it at the trial.

Sadly, there is no cure for preventing scope creep. The best you can do is to try to prevent it, and when it rears its ugly head, try to head it off as best you can. In the end, there’s a good chance you’re going to have to do what your user wants, but don’t just do it; make that an addendum to your project. Spec out the steps required to do it, the time it will take, the impact that will have on everything else, and then get approval from your user base that they really want this done.

Watch Out for Weird Stuff

Watch out for weird stuff. I don’t mean weird requirements, but things that may be new to your team or your environment. For example, if you are building an application that accepts credit card data, do you really understand PCI? Or, maybe you are going to switch from CodeIgniter to Lavarel. You are going to need some extra time (even beyond the normal curve). Keep an eye out for things that might trip you up.

Summary

The bottom line is this: project management is a game you can’t win. If you come in way under budget and time, it’s as if everybody is going to think you’re a sandbagger and won’t believe your estimates again. Keep your eyes on what’s important. Be specific, be nice, be agile, and hope for the best.

Image via Fotolia