Janeiro Digital

“The success of a project is determined at the beginning of the engagement, not at the end.”
- Justin W. Bingham (Me!)

I say that a lot. Probably not enough. I’m thinking of getting it tattooed on my forehead. Next time I have a few beers, please keep a leash on me and yank it if i get in the vicinity of a tattoo parlor. For real.

I’ll say it again. The success or failure of a project is wholly dependant on the expectations that you set at the beginning of the project. When you set solid and achievable expectations at the beginning, you’re putting yourself in a position to deliver quality results on time without utilizing more resources than you initially anticipated at the end. Not to mention, you’re in the right position to adapt to any requirement changes that come your way. Also, remember that setting expectations goes both ways. The client or stakeholder needs to be explicit and clear up front with what they want, and you have to make sure that when you agree on a scope, that you’re agreeing to the same thing.

Now before we get into the details, let me just quickly mention that I hate it when people say you can’t scope scrum projects or give real deliverable dates. For shame. It’s thinking like this that keeps people failing left and right using waterfall methods to do their planning. Smarten up.

Here’s the deal. I do this for a living, which means that I’ve had to learn all this nonsense the hard way. We’re 100% agile and our ADEPT™ development methodology is firmly rooted in scrum principles. Save yourself the frustration and heed my words. Every scope that we put together for our clients includes a prioritized component backlog and a sprint delivery schedule that details sprint by sprint, how we’ll get from the beginning of the project to the end. This is key. We are setting a baseline of expectation that says: “for this amount of money, in this amount of time, this is what can be accomplished.”

Why is this important? Because when the client or business stakeholder wants to try and squeeze in something big, you’re able to point to the sprint schedule and ask them to show you where it could fit, thus leaving them with one of three options:

• - Swap the new feature / component with one of comparable size on the schedule
• - Add resources
• - Extend the timeline

If you don’t set this mutually agreed-upon baseline of expectation up front, what you’ll get instead is the following:

“I’m paying you a lot of money, figure it out.”   Thanks.

We actually find that when we set the expectations properly up front, the client is usually the one that’s coming up to us with the solution.

For example:  “I really want to get this component in there, so lets replace it with this other low priority one”.

Or:  “We need to fit this in, so I’m open to adding another resource, and/or expanding the timeline to have it, because its critical for the launch”.

Glorious. This is what you want. If you put yourself in situations where the stakeholders are constantly trying to shove in functionality after the fact, and you have no recourse or baseline to ground them in reality, you’re probably going to miss your date, and end up delivering something that’s less than spectacular when you do. However, when you’ve got a sprint-by-sprint breakdown of exactly what you’re delivering and when, you have successfully flipped the script, and alleviated one of the great headaches of project execution.

Now hopefully at this point, you’re on the bandwagon, and you’re in the right mindset to scope your next project. That’s good, because I’m going to bring it all together for you in the next and final installment of this mini-drama, where I show you how to make a prioritized component backlog and sprint schedule.

Submit to: