Architecting your IT projects. Problems and solutions
In this short video I will show you why over 68% of all software projects go over schedule and techniques I use and you can use to fix this once and for all.
If you are starting a software project yourself, this video will definitely help you schedule it correctly.
You know, the problem is so prevalent in the software industry, that Forrester research (it’s that big marketing research company) estimates the losses at about 500 Billion dollars a month.
500 billion… Not a small number by any measure, right?
I am doing software development for more than 20 years now and I see projects going so much over schedule and over budget, that companies shut them down midway just because they run out of funds.
When I just started working and was very eager and very excited I started seeing that this problem happens regularly.
I was surprised… You know… most IT managers simply multiply the initial time estimate by 3 or even by 5 sometimes.
And apparently even that is not enough in many cases.
Especially if we are talking about large projects where a lot of people are involved.
And throwing more people at this problem without a good plan is never a solution.
You just run out of money faster.
Just imagine yourself in a situation when you have been working on a project for 3 years, when initial estimates were for 6 month…
On top of that, managers who were running the project on the software development side and the clients side moved on and nobody even knows what needs to be done and what generally happens to the project.
I can tell you, this totally sucks on all counts…
So when I was in that situation, I started wondering…
What are the reasons and how can I fix it?
I researched a lot of techniques for project management with varying success.
Some were effective, others… not so much.
But I started noticing the pattern…
Of course there are many fine details and it’s more art than science, but
the main problem, overwhelmingly is not really that complex and it doesn’t take a rocket scientist to figure out.
For some reason, most times when people schedule a software development project, they only schedule just that…
Just the software development itself.
If you do that, your project will definitely go over schedule.
This is especially true when you order your software development from a third party.
Since they only write your code…
That’s exactly what they estimate.
So it’s up to you to know the rest and depending on the size of your project, you will have much more stuff you need to do.
In many cases I have seen, your software cost is hardly a fifth of the total cost.
Here is what you need to take care of in addition to the development cost:
Research… For some reason nobody takes it into consideration.
But that is why it’s called R&D…
Research and development.
Notice that research is first?
If you have some server side hardware, you need to buy and installing it.
Don’t forget about the network provisions as well.
You must include who is responsible for monitoring the application, what type of failsafe is there if it goes down, who gets called in the middle of the night 
Testing is a big one. Any code needs to be tested. It may take a lot of time depending on the project.
You should also plan ahead for that and you should think of how you are going to be testing each and every piece separately and when they are integrated.
Schedule your deployment and also think about HOW you are going to deploy it and how you are going to update it if needed.
It is especially important if you are doing an off the shelf software or if you are going to be deploying to a lot of users in your organization.
You definitely need some type of installation procedure for your program.
However you look at it, you will also need documentation for your project…
This also needs to be scheduled.
The fastest way to do it is by the way is to shoot some video walkthroughs for your software.
If you are doing a complex new piece of software in your organization, you might want to plan for some live training with your users if possible.
It’s up to you if you need it…
Just see if it makes sense in your case.
Another item you need to worry about is more of an after project thing…
You will need to support your users and help them with any questions.
Your schedule should include training for your help desk as well.
It will look bad if you lunch a project, somebody has a problem and has nobody to talk to.
Or even worse…
You will be the only address for their complaints and you will be getting like 500 calls a day.
If you are doing a large, critical internal project, you might want to schedule DRP (Disaster recovery planning)
This part is again up to you and is not always applicable in all cases, but it is nice to know about it ahead of time.
In many cases large companies require this type of planning and it comes down to costs again.
You should be able to calculate how much it will cost you to have this application down for a day…
A few days…
Or even a week…
What’s going to happen.
It may make sense to schedule some alternative location, backup server and so on.
Another thing close to that is backup and restore planning. Your schedule must include procedures, testing and some facilities to be able to backup and restore your data.
Anywhere you have any data, it is really wise to set up data backups to some offline media.
Tapes, disks, RAID arrays, whatever you use in your facility, but your data must be backed up.
It again comes back to cost of not having it.
The cost of having it will be so minute compared to the cost of restoring it from scratch, that it is always a good idea to backup your data.
By the way, on a side note, you should schedule at least one training exercise, where you actually go through the process of restoring your backup to see how easy it is and how fast it can be done.
I have seen quite a few times where the backup was planned and was even running, but when the time came to try and restore something, it would either take a very long time or was not possible at all.
User transition. Again a lot of projects run into big problems because they forget it.
If your users had a different system in place and you are replacing it with something new, you have to think of what’s going to happen to all their data.
They can’t just “start over”. You need to transfer all their data from the old system to the new system and you need to schedule that.
See how this adds up? If you take any software project and look at it’s real schedule…
I mean how much time it really takes for everything to occur, you will see that the actual development may not even be the biggest item.
I have seen many examples over the years where testing and deployment took much longer than the development itself.
If you think there is some type of magic trick around scheduling your software project or it requires some special knowledge, you are wrong.
Seriously…
It’s nothing big. It’s just a sequence of correctly applied steps.
If you schedule everything you need to schedule, you are already 100 times better off than you were before.
But scheduling correctly is not JUST about that.
If you don’t have a detailed schedule, people will bunch up tasks to the last possible moment.
People slack off in the beginning of the project because nobody really knows what to do and they start working like mad towards the end of the project to “make up time” and to “meet the deadline”.
But realistically if we will be honest to ourselves…
How many times have you seen people actually “making the deadline” so to speak when they are in a mad rush?
Sure, they might technically make it, meaning they report that the project is complete, but in reality, it is full of bugs, problems and stuff you need to fix later anyway.
So you wouldn’t call it complete would you?
In my books “making it” means everything is done and everything is debugged and tested and deployed.
Nothing else needs to be done.
But if you have a detailed and specific schedule, that is realistic and has everybody on the same page and in agreement, you will not have this problem to begin with.
Each person can see the whole picture and how this picture is made up of many tasks.
This lets them see everything clearly and everybody knows what needs to be done.
But that’s not all correct schedule gives you…
Believe it or not, since you split everything into smaller, bite-size chunks, it will let your team get a boost of endorphin each time they cross off one task from the list as complete.
It may look minor at this point, but it actually gives additional motivation because everybody feels like they are actually achieving something and are helping the big picture.
So you see, you have a realistic schedule, that’s one…
Everybody knows what the heck they are doing, that’s two…
And… Everybody feels great, because they see that they are actually achieving some real tasks.
But even that is not all, because now you also have control…
You can see which task is complete and which isn’t, you can quickly adjust the overall progress and anticipate any schedule slips.
Isn’t this great? Not only do you solve your original schedule problem but this also results in additional benefits you haven’t thought about.
So, what can this mean to you?
Of course correct scheduling requires correct architecture and knowledge of the problem.
If your build documentation and architecture are good, you can schedule everything and take everything into consideration.
But even if you apply just this one part and try to consider the whole picture instead of just the development cost itself, you will have a picture that is much MUCH closer to reality.
You will also be able to tell how much money you will spend on doing this project and that will show you how much ROI you can realistically expect.
From my experience if you just look at the development cost, everything looks peachy and your ROI is through the roof, but then reality comes down on you hard.
That’s actually not just me talking, again from the same research I mentioned in the beginning, over 80% of all software projects actually cost more than they return.
Over optimistic schedule is the main factor in this figure.
So as you can see just this one trick you do can save you tens of thousands and sometimes even millions depending on the size of the project.
I’ll take it…
Heck I’ll take it any day of the week now…
Wouldn’t you?
Now remember I was talking about correct architecture and other tricks needed to for your project?
This video was just one of them. I have a bunch more on my web site and I am doing even more every day.
I can help you with your software project as well, so if you have any questions or want more, please visit my web site at www.itholistic.com now.
Facebook Comments: