What's Different?

There are a LOT of project management tools out there - and yet there are still a lot of late software projects. What gives?

The project management discipline evolved as a general purpose methodology to introduce some consistency and science to the way in which projects - any projects, regardless of the industry - were managed.  And it worked for a while.  Well, sort of.

Even with these tools and methodologies, most software projects are still late.  And most users of the general purpose tools are unhappy with them.  Why is delivering software on-time still so tough?

At Devshop, we believe it's because of the approach.  A general purpose approach simply doesn't work very well for software projects. There are all sorts of software-specific dynamics and risks that just aren't being accounted for. That's why we're here.

The Devshop approach - Fresh thinking built-in

Devshop started with a blank sheet of paper. "What are the factors throwing software projects off the rails?", we asked. Well, that's easy:

1. Requirements and Schedule

   Let's face it. After the first draft of the schedule, word is out and that's the date you often have to stick to. But requirements keep changing. Not being able to quantify and easily understand the impact on the schedule when requirements are changed, puts the development team at a serious disadvantage.

2. Estimating time is difficult

   We're all pre-disposed to see the similarities in the things we're about to do based on the things we've done before. When estimating time, it's the things that are new that need the most attention. Inaccurate time estimation is one of the biggest drivers of unrealistic schedules.

3. Distractions

   Developers are handy to have around. They can do so much more than write code. Like fixing mail servers, installing CRM tools, fixing PC troubles for other folks in the company. Trouble is, when they're doing that, they're not writing code. These things have a tendency to catch up with you and scuttle your schedule faster than you think.

4. Is this schedule realistic?

   Who knows? Probably not (statistically speaking). Quantifying and articulating how "sure" you are about a schedule is tough. Unfortunately there isn't a common scale for this type of thing. But if you can't quantify or articulate your confidence in the schedule, how do you know when you can go ahead and make a promise based on it? Devshop has figured out a way.

5. What did we learn last time?

   When you've completed a project, there are likely some things that went well and other things that blew up. You learned some things. Maybe you even had a meeting to discuss what happened and changed your process so that some of the problems you identified will never happen again. Trouble is, those problems likely won't be the ones that actually happen again. It will be entirely new things that crop up. Wouldn't it be great if you could take the knowledge you gained from the previous project and apply it to your next project, helping insulate it from new risks, so you can be successful despite them?

The Devshop solution

Devshop was developed to deal with these factors. If you've ever used a project planning tool before, you'll feel immediately at home with Devshop, but you'll love the built-in capabilities to help you with each of the software-specific problems mentioned above.

1. Requirements tied to Schedule

   The Golden Rule: when requirements change, time estimates must be revised. Unless your application actually tracks requirements and ties them to the schedule for you, you're left doing it by hand, or worse, not at all. Devshop tracks both and knows that when requirements change, time estimates need to be reviewed. It highlights them for you so that you can easily make adjustments.

2. Time Estimation

   Accurately estimating how long it's going to take to develop software is difficult. Accurately estimating how long it's going to take to develop new features in a software product is even worse. It usually takes years of experience to get it right. Devshop can help. It tracks the estimates coming from each team member over time and feeds the results back to each team member as they are about to make their next estimate. Now team members can see their own trends and use that information to improve future estimates. An appropriate amount of time is continually budgeted for and the schedule is automatically updated, based on the historical trends of planned versus actual durations.

3. Managing Distractions

   The trouble with distractions is that each instance seems relatively harmless. But the reality is, they do add up quickly. It's the sum of the distractions that wreak havoc on project schedules. Distractions tend to be highly individual as well. Some people end up being the "go-to" person for unrelated catastrophes like someone accidentally deleting all of their email. Devshop tracks the rates at which people get pulled from projects to do unrelated work, and automatically adjusts the schedule accordingly. More importantly, each distraction can be recorded and the cumulative impact on the schedule can be explained, quantified and justified.

4. Schedule Confidence

   How sure are you that the current schedule is achievable? How sure is "pretty sure"? Devshop keeps it right in front of you at all times: a Schedule Confidence score is continuously calculated based on what portion of requirements, designs and time estimates have been approved by the right people. The more designs and requirements you have assembled up front, the more approvals you have in in place for them, the higher the Confidence score. Change some requirements mid-way through? The score drops, providing true visibility into the impact of requirements change on the schedule.

5. Bring it forward

   When planning a new project, simply add people to your project team and Devshop will apply those team members' individual trends of Time Estimation and Distraction Rates to help you build a realistic schedule the first time. Of course it will also self-correct during a project, but you'll already be way ahead of the game right from the start.

It's a team thing

Unlike most project planning tools, Devshop is for the whole team. That doesn't mean filling up everyone's inbox with reminder spam, but instead, giving them appropriate input into the scheduling process and providing individualized views of the schedule. What about developers working on multiple projects? No problem - Devshop understands that and provides multiple views into multiple projects to help you keep everything straight.