By David Shirey

PHP Project Management

By David Shirey

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.


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

  • Dan

    Great post, really hit a nerve with some issues I’m dealing with at the moment.
    Scope creep is the biggest problem we tend to have on lots of projects…!
    As you say, diplomacy is very important when dealing with it!

    • David Shirey


  • Hector

    can there be a php tutorial based on ctype functions made and how they can be use for validation

    • David Shirey

      Good idea and I have scheduled it with Tim. Thanks.

      • David Shirey

        And, now that I am in here for another comment, I guess I really should get to work on this. Sorry about the delay. I will try to get something out in a week or two.

    • david shiey

      I see that Tim has published the article I wrote on Ctype functions which was your idea. Let me know what you think, does it hit what you wanted it to?

  • Very interesting. Still searching for the right project managing Tool…
    Hope to find some recommendations…

    • David Shirey

      I am sure that people will chime in with what their favorite is. To a great extent it depends on how big your project is (that is, how much complexity or layers there are), what people are expecting in terms of reporting, and what the time frame is. I have used a number of tools from Project to web based things like Asana and Highrise, but most of the time I just use plain on excel. I know other methods have advantages but it just doesn’t seem worth it to me (although if you want other people to be able to see the project status 24X7 then some of the web solutions are pretty nice.

      In the end, it is not about the tool as much as it is about keeping everyone focused on today.

  • Thanks for the article Dave. The line between fair and pushing it too far on both sides is a constant see saw that is best calmed with a clear agreement and a good solid customer partnership otherwise things can quickly go pear shaped!

    • David Shirey

      Go pear-shapped. I like that. I think I will use that with all my clients. Giving you full credit, of course. :)

  • Really good article. I’m a PM and the bits about repeating to everyone, all the time, about what the project is going to achieve, what it’s all about, it REALLY KEY. People forget these basic things and get distracted by the Other Cool Stuff that they could use.
    And evaluate every bit of scope creep against those initial requirements – if they help the project meet it’s goal – then I will consider adding them in after deciding on the impact.

  • Scope creep has been the biggest thing for me to get my head around as I do more freelance projects and need to deal with it directly. My solution has been to document everything (meetings and conversations) and get the client to review and sign to make sure there is considerably less miscommunication. So far so good.

    • David Shirey

      You are right. Scope creep is very, very bad. The best way to deal with it is with public executions or torture (of those bringing up new things), but with these damn liberal courts it is getting harder and harder to do that. Documenting everything is the best way but in the end people are amazingly resistant to the truth. In my spare time I also work with at-risk teens and I see very little difference between them and many business people. They both tend to refuse to accept the truth. Guess it’s a human sort of thing.

  • awesome..
    would you mind to give me a sample of your plain excel file ?
    i`ll learn from that. thank you very much

    • David Shirey

      Unfortunately, I don’t have any that don’t have client info in them, but they are very simple. Columns for project ID, Description (as in a title), owner, start date, hours estimate, current status code (like W for waiting, I for in process, etc.), short description of where project is at (50 characters or so with a date – 4/12 – Waiting for user to check function output. Then I have a link to, generally, a word document where I keep detailed, dated info on what has happened in the project as well as any contact info that I need. From this I can quickly refresh my memory about what this is all about in case I have to wait weeks for the users to get back to me and I move on to other things.

Get the latest in PHP, once a week, for free.