A late project? Well, it has been known to happen. According to my wife (who has got a far better memory than me), almost all my projects are late.
I attempt to explain that they are not really late, someone has just decided to add more features. Or we all decided to postpone the release, to make sure the delivery had the required quality. Then she goes “But the project was supposed to be done last tuesday, right?” and I’m like “Yes, but..” and she cuts me off “So that makes it late.”
A popular term is “definition of done“. Maybe we should also discuss another: “Definition of late”. The definition of done may be challenging to define, and across an organization it’s very likely to mean different things to different people. One would think that definition of late should be easier to define.
“The project should be done by November 1st. If it isn’t, then it’s late!” Right. But wait. Done? If the project isn’t done until September 1st it’s late. Suddenly avoiding being late relies on something being done – and we just agreed that “done” is a tricky topic. Or is it?
When we postpone the release to production in order to do some additional QA, we’re not really late right? We’re done with the project, we just haven’t released it yet. That must be okay? Or does the lack of quality mean that we tried to deliver too much in too little time?
And if the project owner asks you to add more features, surely that’s no problem. He is the boss, after all. I suggest you explain to him that it will postpone the delivery of all the value created so far. A better solution would be to deliver what we agreed, so that the project outcome will benefit the customer as soon as possible. Then we can add more stuff in the next round.
So, back to being done and late. You see, the thing is that the customer rarely considers a project as done before he can create value from the result. So if your customer can’t create the expected value from whatever he ordered from you, then you are not done.
And if the customer can’t create the aforementioned value by the agreed delivery date, then my friend..
You are late.
It’s strange how when a company grows, it suddenly fills up with people not really doing anything. So called management. I mean sure, they’re doing SOMETHING. But they’re not creating. They’re not producing.
No wait, that’s not right either. They’re producing stuff like policies. Processes. Rules. Sometimes they’re even yelling and pointing fingers. I’m one of them management types. That is, I try not to point fingers too much, but I’m quite keen on the rest of it. Well, I’m actually mostly a process guy. I happen to think they are quite useful. Rules on the other hand, that sounds a bit harsh, doesn’t it? And what does a policy really tell you, when you get down to it?
Our policy is to have policies
A policy is some kind of general principle that the employees and / or company commits to. “Never say no to a customer.” “You must change your password twice a month”. “In order to protect the environment, you are not allowed to print emails.” Stuff like that. If you are really lucky, you’re in a company where policies are defined as the stuff your boss rants about before they give you access to the alcohol at the Christmas party. He’ll say something like “From now on, everyone must work smarter!” and you will go “What does that even mean?”
To be fair, having sound policies like “Don’t share company secrets on Facebook” and “Don’t say bad things about our customers, at least not in public” is probably a good thing. But they seldom tell you exactly what to do in any given situation.
The beauty of the Process
A process is a documentation of the best known way to solve a given problem or situation. “Best known way” is the key part. That means every time the road changes, the old process no longer applies. The process must be changed with it. It also means that every time someone figures out a better way to do something, the process must reflect it. Implementing a process for the first time doesn’t necessarily mean you have to change much, or even anything at all. The process is there to document how something is done. And how it’s done right. How to update a server. How to service a car.
What’s the point of that, if you’re already doing it? Well, if you got more than one person performing any given action, it’s very likely that there are as many variations on execution as there are persons. A documented process improves the chance that more than one person is performing the action in an optimal fashion (according to the process).
Simply writing down the process the first time, will probably trigger someone going “Hey, that’s not how I’m doing it!” – and you’ll discover that four out of five guys where doing it wrong. If it’s a complicated task, the process will also help people so they don’t forget any vital part of it.
Last but not least, documenting a process is the first step towards improving it. Which is another subject, for another post (or series of posts). So I guess that’s a cue for me to stop writing, for now.
I’ve been surfing the web since it arrived in the 90s. So why do I still click several times on the mouse when a page fails to load within a few seconds? I know very well that with each click I’m sending another request to the web server. I’m basically stabbing it to death with my mouse.
So why? Because I’m freakin’ frustrated, that’s why. I grew up with MTV, if nothing happens within 3 seconds I get so bored I throw a fit or fall asleep. The average user sense a delay if it takes more than one second for something to happen after they click their beloved mouse.
So what does that mean in my world? It means that when developing a new web based service, focus on speed is vital. I don’t care how many great features you cram into the product, If it doesn’t look good and load fast you’ve still got a problem. Below are some basic guidelines when developing your new website.
- Surfing your service (loading the login page, logging in and clicking on the available menu items) should on average take less than one second per click, and never more than two seconds.
- Any action that takes more than three seconds on average need some kind of visual notification. Put in a a load bar or a blinking “Please wait” to make sure the user doesn’t forget that he actually did click when he wakes up again.
- Nothing (including reports) should take more than 10 seconds to load. Ever. That’s an eternity. Most people on Facebook was born less than ten seconds ago. If your report takes more than ten seconds, pre-fetch it and store it in cache or on disk. Or you can send it to the user async via email, so that you can respond to the user immediately with “Your report will be delivered to your email shortly”.
But what about the internet itself, you ask. My server is super fast, but my site still loads slow for some customers! A study showed that on average it takes 6 seconds for a page to fully load. Only 0.6 of that time was server processing. 1.4 seconds was the actual network traffic, and 4 seconds was processing on the client computer.
So your code should be lean, just as your development process. Hopefully your service is about improving a process that creates value for your customer. That means the faster your service is, the more value (and less frustrated) your customer will get.
So the next time your customer or product manager asks for an animated duck in the background of the new administration interface, make sure he knows that it will slow down the load time of each page with several seconds. When you ask “Does the duck add value?” and your product manager says “Yes”, you can kick him in the knee and tell it’s from me.