11 Authority on both sides

While it’s great having stakeholders who are really invested in the process, it is imperative to have a key decisionmaker on the client’s side who has the authority to cut the bull and make a decision when the debate has run it’s course, and enforce that decision with the stakeholders.

In this respect it is important to have authoritative project managers on both sides, and ideally they’ll have a rapport to facilitate the project and bring it to a satisfactory conclusion for everyone involved. Not all the stakeholders will be 100% happy, but that’s the client-decisionmaker’s problem, not necessarily yours.

John

posted at 03:57 pm on April 16, 2004 by John Bedard

12 Individual needs

It often seems logical to ensure all your team members are on target towards the project goal 100% of the time but you should never neglect the emotional and individual needs each member requires. This shows as a project manager you care and helps keep everyone happy and focused on the project when they are supposed to be.

posted at 06:10 pm on April 16, 2004 by David Jones - Elegant Design

13 A lesson for Team Leaders

As a part of the course I’m doing i was recently involved in a group project where we had to design a solution for a client.
I took the role of Team Leader, and while our project was never to reach a development stage I relate very well to your article. Being my first leadership experience it took me a while to find my feet and i fear i at one stage ruined the project for all of us because i didn’t understand it properly!

This is an excellent article highlighting some key issues in project design and development. Great Work!

posted at 11:28 pm on April 16, 2004 by Michael Watts

14 What's it really all about?

God, there’s been some fantastic responses. I know from experience that Projects rarely end up exactly as you thought they would when you first began. The aim here is to provide a simple process that will help you save your sanity, secondly save your company from overruns that the client won’t pay for, and thirdly save the client from themselves. Much of the time clients have a thought and the Project Manager’s role is providing direction and defining a deliverable. I have worked with a client who never ever wrote anything on paper. They never read any documentation. Boy, every day was a minefield. But there had to be a way to protect myself and the company I was working for. Hey, what it seems everyone is saying is that there is a reason we are Project Managers. We do like the excitement and challenge of methodically getting to a finish line. We really do like the heat, we just don’t like to get burnt.

posted at 11:33 pm on April 16, 2004 by Joe Di Stefano

15 DSDM

I’ve been trained to use DSDM ( http://www.dsdm.org/ ) in projects. This can include everything from websites to building a new city.

The fun thing of dsdm is that only money and time are fixed, everything else is variable — and as such opposes the inflated balloon a little bit.

Scope creep is a fact of life, because during a project people learn new things that could never be envisioned initially. That’s a fact of life.

I have never done a project without scope creep.

I once participated in a project where the initial signed documents where treated like a Holy Script. By the time the project was delivered everyone was dissatisfied, although the project was delivered on spec.
Since it was one of my first experiences as a junior on a team I vowed never to do another project like this, because it took the fun out of working and it missed target since the target was moved, but the trajectory wasn’t.

And thus I found my thing in the dsdm method. And thus I have done a lot of projects that ended somewhere else than where we started, with nothing but very happy clients, within budget and within time.

I just inflate a lot of different balloons along the way (sold as prototypes), but I keep a countdown clock to Moment X visible for everyone. The closer we get to Moment X, the smaller the balloons ;-)

And that’s the same mantra as used by Joe: “We only have limited time, so we’ve got to make some decisions now what is included and what’s left out”, also known as MoSCoW: – Must Have – Should Have – Could Have – Would like to have, but not this time around.

What functionality is grouped under one of these requirement groups is a matter of inflating the balloon along the way. The closer you get to delivery time, the less is grouped under Must Have, and most of the “must have’s” have been delivered or shown in a previous prototype.

posted at 01:29 am on April 17, 2004 by Martijn ten Napel

16 on a micro level

So interesting to stumble onto this discussion. I’ve dealt with the same issues, but on a micro level.

I teach web design to high school kids, and have them do sites for real clients whenever I can, usually people who are starting small businesses and have called the school looking for a way to get a site on the cheap.

Even though I hate the business end, I force my kids to do a ‘scope of services.’ We have a client interview and try to ask the right questions so that we understand what they want/need. Often they aren’t really clear themselves.

Then each kid tries to write a SOS. I give them a formula; one short paragraph saying something to the effect, ‘Great meeting you, we’re excited about the project and think we have a good understanding of what will make the site work splendidly for your target audience and your business. Eager to get started. Below we’ve scoped out what we propose to do. If this meets with your approval, sign and return the form with your deposit and we’ll get started.

Detailed description of project leaving as little room for interpretation or misunderstanding as possible.

Concluding sentence: What we’ve described above constitutes the entire project. Any work not included in the above will be billed at an additional hourly rate of $xx.xx.

We really look forward to working with you on the site.

Sincerely,
X

I explain that if you proceed this way and get the ‘lawyering’ out of the way right at the beginning, you can go on and be casual and friendly later, but if you don’t start out with absolute ruthless clarity at the beginning, things get murky and uncomfortable, and usually ugly in short order.

It usually goes something like this, starting with a phone call about a week after the project has started:

Client: Listen, I was talking to my brother-in-law and he mentioned that his site has a guest book, and I thought, wow, how great would that be? So could we add a guest book to my site?

You: Er, yeah, I guess we could. (now starts wondering if the client assumes that will be included in the already-agreed upon price, or knows it will be extra, and if so, how much extra…) Either way, you lose, because if you don’t charge them extra you’ll resent the job and make less, and if you do they may get angry and feel you’re trying to up the price and take advantage of them. The relationship sours and you don’t get return business or referrals.

If you have done the SOS They’ll say, I know this will be extra, but could we….blah blah blah?” you can say, “Sure, I’ll send you a change order pricing out the guest book, and as soon as you sign off on it we’ll go ahead.” And then they can decide if the addition is worth it or not, but you won’t have soured the relationship.

Had this happen last year with a good client. We were doing a site with animations of several rooms of a house for a children’s book. Did the SOS. Started work, showed her the preliminary, which she loved, but she asked “What about the basement?” I thought maybe she was right and we had forgotten it, but was able to go back to the SOS and see that it wasn’t included. So instead of a horrible situation where we remembered the agreement differently and both were sure we were right and oh dear, we have a tense situation on our hands, it was fine, and she decided she didn’t need it. The job turned out quite well, she was thrilled and sent us other clients.

So important to start with clarity, get it in writing, and then get on with the job of creating something great.

posted at 11:27 am on April 17, 2004 by susan bein

17 What if?

What if one of the balloons burst from too much pressure?

posted at 02:03 pm on April 17, 2004 by Dante-Cubed

18 What if?

If the balloon burst from too much pressure? That’s easy, you go to K-Mart and buy a whole new bag. Then you either inflate another, or many, as mentioned by Martijn ten Napel above. Or if the pressure has been really bad, it means you probably don’t have a client or your sanity. So, you’ll be filling them up with water and dropping them from tall buildings.

posted at 04:14 pm on April 17, 2004 by joe di stefano

19 In an ideal world...

Having been on both sides of thie fence here I think this was a pretty “safe” article.

On the one hand being upfront and honest is key when you are acting as a vendor.

On the other hand…you do it too often, or you don’t fully explain and get buy-in from your client…they will hate you even more and think you’re a predatory vendor doing a few things:

1) Stalling: You’ll need to provide some kind of tangible update and evidence of your good faith at this “honesty” session.

2) Screwing: You’ll also need to get 100% buy-in from your client that stopping or re-scoping is the right thing to do. Otherwise, they’ll just think you’re trying to eek more money out.

Here’s why… (that other side of the fence)

1) Organizations don’t necessarily have a good grasp on what doing a fully developed web-application can involve on the part of a developer and development team.

A great example is a simple text change that my company needed to make. We specified the change in the text. That text appeared on approximately 10 pages. Only 8 were changed by the developers and they were blamed for poor execution of our change request.

I have a feeling that the developer thought they had changed everything. I think that the developer needed to ask for the specific pages where those changes were to be made.

On our end, we saw it as something simple. In reality…the developers needed more time and information that wasn’t provided. (ie. the scope for the change request wasn’t defined well)

2) Organizations aren’t as flexible as developers.

When budgets get approved. That’s typically it. In some cases it takes moving mountains to get budgets changed. If you’re dealing with a business unit inside a larger organization…you better be COMPLETELY sure that you know what you’re getting into regarding scope changes and budget adjustments for a project.

Remember…web-developers (yes even great ones) are a dime a dozen. And more often, the best developers are just consulting front-ends that have actual developers in China or elsewhere doing the actual work. So remember your competition before you start hitting that stop button!

You have every right to. And it is nearly always the right thing to do. HOWEVER, organizations don’t “get it” so don’t assume they will magically with an email. You better be 100% clear with them.

3) Organizations are notorious for business-rule changes that effect whatever you’re working on.

Don’t assume that a change request is coming out of the blue only to you! A lot of times things change in the course of a development project internally at a company. Especially one that is developing a complex site or web-application.

Expect it. Build it in if you can. And keep in close contact to help anticipate it.

Remember…only so much can go into versioning with an application. Business rules don’t get versions. They happen and that’s the end of the story on the date they go into effect.

Your clients will see your ability to keep up with them EQUALLY as important as your ability to deliver a quality project. So put on your jogging shoes and get creative with how you handle these things.

In a lot of cases you’ll be able to make a small change that won’t be a big deal. But in other cases you might need to find a way to build your current version in a way that allows the company to do what they want, but then release a more elegant interface or procedure for that in a future release.

Never say no if you don’t absolutely have to.

So in a lot of ways the relationship between the client and the develoer aren’t adversarial. But…it is EXTREMELY easy to fall into that pattern of discourse with them.

The best way I can help you think about it, and the way that I do…

Think about a magical box where you type in what you want and then reach in blind and hope to pull out exactly what you want.

In many ways that’s how businesses feel. They want a very specific thing. However, they are a bit blind in terms of thinking about all the bells and whistles it needs. And when they reach into the box they can only feel the basics of what is being built. That can cause questions, revisions, and worry on their part.

You are inside that box trying to provide them with as much feedback as possible. The more accurate, timely, and complete the feedback is that you provide the better that hand in the box will understand what it is grasping.

Ultimately you want the hand to grasp exactly what it wants, and understand how it got to that point. Problems will occur along the way. The more the hand knows…they more it understands the shape it feels. The less it knows…the more it thinks it’s being tricked.

Be honest. Be complete. Be timely. Be COMPETITIVE.

posted at 10:19 pm on April 17, 2004 by Keith

20 Irony is too great

One of the major reasons I’m into the internet seriously is because a few years back I got addicted to the “Water Balloon Drop” game on Shockwave.com. I mean, I didn’t even know one thing about HTML till about November 2002, but still it’s ironic.

posted at 11:59 pm on April 17, 2004 by Dante Evans