Open your application. Start hitting Tab on your keyboard. Look where focus goes. Is order intuitive or random? Are all controls accessible?

Try to fill in form in your application. Go through edit boxes, check boxes and radio buttons with Tab. Can you get to another control you are expected to fill with one Tab press? Each time?

Setting correct tab order is a small, yet dull, development task. You don’t gain much completing the task. On the other hand you lose much if you reject to set the tab order properly. Your users get frustrated with the product. User experience peaks down. Everyone starts using competitor’s software. Your company bankrupts... OK, I went too far with that one. However that’s another small thing usability is built from.

Whole usability issues series.

The other day I wrote about setting rules and things which usually need to be done to have new arrangements working. However you’ll see some of your Great Ideas which you’ve implemented in the work environment don’t look as great as they appeared at the beginning.

What to do? Run in panic? No, not so clever. Pretend it’s all OK? Well, at least that way you don’t admit you’ve failed, but I wouldn’t say it’s worth to add everyone another dull task just to show you aren’t so great as you’d like to be. Change the rule? Oh yes, of course!

If something doesn’t work in your house you either fix it or throw it away. Why shouldn’t you do the same with processes in your work? Don’t force people to do unnecessary work or they’ll force you to look for replacements. It’s a fair deal, isn’t it?

And no, your reputation among team won’t be harmed. Quite the opposite.

Few days ago Ray White with his post about buying versus building software components reminded me my very first post on the blog which touched the same subject.

Over a couple of years I’d add one more thing to the discussion. Remember what your core business is. Sometimes you can judge building software just for yourself basing on functional comparison and cost analysis. However before making a decision go deeper.

Think if that would bring your company forward? How much effort you’ll need to maintain that piece of software. How many projects you won’t be able to handle because of building software tools inside. What’s the alternative cost?

I think over time I evolve more into “leave it to professionals” kind of approach. What is yours?

Make your application looking nice. I don’t say every app has to be shiny and polished like Vista, but make it looking good enough for your users. If you write for system administrators then console should be enough. But if you do anything more, even when your UI can look ugly don't make it sloppy. Controls set straight. Buttons placed intuitively on each window. Toolbars don’t changing their appearance randomly. All controls and options accessible with keyboard.

You get much with little effort.

Whole usability issues series.

You’ve heard that probably.

“Your projects are usually late. Do something about that. We lose credibility in the eyes of our customers.”

Ouch.

“And another thing. Last schedules you’ve prepared are unacceptable. They should be cut at least by a half.”

And now you’re confused.

“Sure, feel free to cut deadlines by 50% and yes, this time we’ll deliver on time.”

Except of that’s not true.

To be honest I always feel uneasy when I have to deal with those kinds of situations. Yes, I understand so called business perspective. I actually can imagine that a couple of months of schedule can be unacceptable for a customer. I know that easier or more appropriate solution from the technical perspective can be rather not suitable business-wise. However at the end of the day you need to deliver. Hopefully something within scope, time and budget.

There is no easy answer how project manager can discuss those accusations. Several things can help however.

1. Make your estimates as reliable as you can. Create something what you believe can be achieved. It’ll be easier to discuss that later on.

2. Look for a compromise. A couple of man-months of development can be covered differently with different resources. You need different buffers for a newbie than for a veteran member of the team.

3. Remember about your environment. Estimates shouldn’t be done for veterans when you don’t have any in your team. If you have a number of other projects to do don’t consider there are none.

4. Be assertive. When something isn’t reasonable, point it. When something can’t be done, explain why your team isn’t capable of doing that. Describe what needs to be done if you are expected to achieve that goal. More experienced team? Some training maybe?

5. Talk about merits. Don’t start “it is so because I say so” type of discussion. It’s a dead-end. Think. Were past estimates good? Where you made mistakes? Why? Is that similar situation in any way?

6. Admit where you failed. Don’t try to play the hero because most likely you’re not. Most likely at least several of your estimates were wrong. Don’t try to hide that. Try to name reasons why it happened so. If it don’t help with the current discussion at least you look more credible with that.

And remember one thing: it isn’t a win-lose only scenario. You can end with win-win or lose-lose too. The former should be your goal.

Now you’re a manager and you have some power. Now you’ll show them. You’ll set up The Rule.

Of course we all know The Rule is reasonable and will be an improvement. You do it because you believe it’ll help, not just to show you have the power.

You announce The Rule to all interested parties and that day you go to bed with great feeling. You did something. Everything will be better now.

Then Mr. Reality comes to kick you in the ass. No one cares about The Rule. Everyone works exactly the same as before. Don’t they see it would all be better if they obeyed?

Most likely they don’t. At least not all of them. Not everyone will be convinced by your words, they expect to see results. And they won’t see results unless they start to obey The Rule. We have a deadlock here.

The thing you need to do is to check regularly how people deal with The Rule. Remind them they should do what they are asked for. Tell them once again why The Rule was invited. Hopefully after several iterations everyone will treat it as a natural part of their workplace and you’ll no longer need to think about that.

Which features are the most important? For salespeople newest ones. For marketing your application differentiators. For developers those which bring interesting problems to solve. Unfortunately usually none of them actually eat their own dog food. And for users the most important features are those which are used the most frequently.

If you need or want to work on usability focus on those functions. It can be search and time you need to wait to see first results (first 10, not all 16,9 million of matching results). It can be filing an invoice for simple invoicing application (what a surprise). It can be writing or test formatting for word processor. You name it. It’s your software.

Checks how accessible are those features. Measure how fast they response. Verify if they are easy to use. Think how intuitive for a new user they’ll be. Focus only on features which are used the most often. When you have no ideas how to improve them move to next, a bit less frequently used.

Whole usability issues series.

The other day I had a chat with one of my friends. He told me one thing.

There’s nothing more demotivating than being helpless. You only frustrate yourself.

We were talking about taking responsibility for a part of the company as a chance to deal with issues which annoyed us. We considered that as a chance to do something about that instead of ranting about the situation. But there is another perspective.

It doesn’t matter if you’re manager or tester – there will be thing which you don’t like and you don’t want to accept them in the long run. It can be atmosphere of the workplace, it can be lack of order in project management, it can be constant context switching, it can be beef-head boss, it can be anything.

Now, you either see you’re able to change the annoying issue or you end up as frustrated employee and eventually leave. Yes, usually managers have more tools to change the environment they work in, but the rule is general. If a developer can’t go through with his great ideas how to improve development his frustration will rise. If a project manager is struggling to move her projects a bit from the complete chaos with no effects she won’t be happy with her job.

If you’re a manager you have to give your people chances to change their workplace. The place they work in and the way they work. It doesn’t automatically mean you have to agree with each idea, but if you listen you’ll hear a lot of reasonable ones. Except of improving performance of your team you’ll also limit their frustrations.

You take this new app which is told to be better than the one you use at the moment. If you’re lucky it’s intuitive and you don’t have any problems to set it up. Then you start working. And it hits you. Important operations are slow. Not dramatically slow, but significantly slower than with the old app.

Take new shiny Vista box with new shiny Office 2007 and sometimes it’ll freeze for a second. Annoying. Your good old XP with Office 2003 didn’t perform like that. Take Google Spreadsheet try to cut and paste a piece of cells. What the heck is happening? Am I faster than the app? Oh, yes I am. It wouldn’t happen with good old Excel.

The clue here is responsiveness. How fast application will answer to most often executed operations. Lightning fast? Maybe as fast as industry standard? Or you’re just too slow?

This is the big issue especially for web applications. Responsiveness of the web is significantly worse than desktop application. As far as we used WWW just to browse websites it was natural since it wasn’t a replacement for an existing application but a completely new one. With financial, CRM, project management or office apps we’re trying to replace desktop software we use every day. If they’re slower the user experience descriptions will definitely use the word “frustration.”

Focus on your software responsiveness, especially on the most important functionalities. Compare to other, legacy software in your market. If you’re significantly slower, well, that’s a sign you have a task to do: improve.

Whole usability issues series.

I was writing here about usability of applications on a couple of occasions. And since usability is made of small things I thought it’s a great idea to run another series of short posts on the subject.

There will be post per week published unless I’m off on vacations or some disaster happens.

Usability issues so far:

Responsiveness
Most frequent used means most important
Nice enough
Tab order

There are at least two answers to the question whether functional specifications are useful or not. Agilists would say specifications value is low since software will be changing significantly during iterations. The other party doesn’t even start a project without singed detailed functional specification.

I think both sides are right. Sometimes. It depends on client you work with. If you have a good partner to employ agile approach and you value this technique, go for it. As far as you are able to find a consensus with your client you won’t need detailed specification up front. Probably some documentations at the end of the process will be enough.

On the other hand there are customers out there who will exploit lack of defined functionality range to switch into feature creep mode. There will be a lot of new critical functions created on the fly. There will be a lot of interpretations how different things should work. Your only shield is anything which was formally agreed before. Possibly functional specification signed along with the agreement.

Actually it’s neither the size nor the type of the project which plays the main role here. Not even your software development and project management methodologies. The client is important. Let’s take a typical implementation for mobile operator (things I deal with every day). Project timeframe between 6 and 12 months. With the same system, similar scale and two different customers we need two approaches.

One client sets us a list of goals and work actively with us during development. We don’t even try to create detailed description of developed features and we expect a number of changes when they see first result of our work. Since client attitude is reasonable and they don’t bring things completely out of agreed scope it works fine.

Another client brings very strict verification phase when a number of new “improvement ideas” are submitted as bugs. As far as we don’t have detailed scope of work there will be some interpretations how different features should work. And since the requirements are changing over time (which is fairly natural) no specification means feature creep. A feature creep invited on the very late stage of the project which blows the schedule up.

Since I could say which style I prefer it doesn’t really matter. What matters is which style is preferred by our beloved clients. We can adjust ourselves. But the answer to the question from the title will remain the same: it depends.

You could have heard that several times.

How much time it will take to complete that?

Two months. But we can’t complete that project in two months from now.

Why? Isn’t that just a matter of resources?

No it’s not. Whole core team is at the moment fully engaged in other project and we’d need at least two of them here.

Let’s take two of them then.

OK, but consider the other project as late by half of the year. Fair enough?

No. Can’t you find other people to do job?

Yes I can. I will have them in the office in 2-3 moths. And after another half of the year they’ll be ready to undertake the task...

Resources (what a “great” name for people) are almost never time independent. When you talk about a team, they probably have work planned for next several months. Sure, you can go, change their priorities but you should always consider alternative cost of doing that.

It’s not only people’s work which costs you money. There are other commitments also. Commitments your salespeople have already cashed in their income forecasts. Commitments you’d have to break if you took some people out to other tasks. With all consequences. Consider those broken commitments as your additional cost. Alternative cost of focusing on something else.

Now you have the full picture. And full cost of telling the customer it’ll be done in a couple of months.

By the way: you’re really lucky if your salespeople understand this concept. Personally I’m lucky enough to work with really reasonable sales team. They do understand.

My last posts are mostly about dealing with workload. The reason is simple – last weeks at work are pretty hectic. Sleeping for 4 hours isn’t something very unusual these days.

Today I have another self-management tip. Leave less important things aside. If you lack time you should spend it neither on task switching nor on unimportant errands. That’s pretty obvious. Unfortunately we tend to forget about that.

And there’s another trap. We usually set unimportance level way too far. As a result we don’t have enough time to deal even with “important” tasks. The direction should be opposite. Start with the critical things and until they’re finished don’t touch anything else.

The rest should be delegated or forgotten.

Unfortunately for me it does mean significantly lower posting frequency on the blog, which I believe you’ve noticed. I hope to be back on track in a couple of weeks.

At the moment we’re about 35 people here in Wind Mobile. We’re still considered as a small company. And sometimes clients still considers that as an issue.

Yes, I know, I shouldn’t be surprised, yet I am. At least partially. While I understand relatively small size of the vendor company brings some risks for the client it also brings a list of advantages which are usually underestimated.

Flexibility

Small is flexible by nature. If you’re small you much easier adjust yourself to environment. To ever-changing requirements. You’re much quicker when it comes to react for new situation. One of main big players on our market is known they never deliver any ordered change request in time shorter than a couple of months. Even if it takes them a manday. We are on the other end of the scale.

Cooperation

When you’re small you value relations. Since you don’t have loads of salespeople you sell via references. And you don’t have references unless your clients are happy with cooperation with you. Therefore you put much effort to improve the cooperation. Maintenance people like you. Product managers like you. It’s a win-win.

Engagement

Since each similar deal is relatively more important for small company than for a big one small organizations usually care more. If you don’t have comfort to be able to trash a project with almost no negative consequences for the company your level of motivation will be way higher. You’ll just care more.

And yes, choosing a small company is a kind of risk but most of the time it’s a worthy play. I don’t say that just support my ego. I’ve seen much more failure projects delivered by big players just because the vendor failed in one of above criteria (usually in all of them).

Of course you can always bring the old motto “No one got fired for choosing IBM” but at least don’t try to state you choose the best option.

I guess you were in a situation where you knew everything about a problem. What happened (that easy since you see what happened). Why it happened (there they come, first simplifications). Who is responsible (I got you, Mister Guilty).

Then you have several options.

• Wait actively until the problem will resolve itself. In other words do nothing. That’s what most managers do. That way you avoid difficult discussion and all the hassle.

• Yell over them. Get people who are responsible for the problem. Tell them where they were wrong. Tell them what they need to change. Get them back to work as soon as possible. You know better.

• Talk and listen. Tell how you see the situation. Ask people who you believe are the source of the problem what they think about situation. Ask where you can be wrong in your judgment. Try to find the way to avoid this kind of problems in future. Jointly.

I always tried to avoid running someone down. But even in situations when I came to the point I was ready to choose that option open discussion with mind set to listen not to yell brought much better results. Like recently when instead of one issue I was sure we had we found two others, completely different problems.

Last time I got an advice for those who want to fight with their backlog. Today I’d like to share some ideas with those who like their backlogs and want them to prosper in great condition.

1. I’ll do it on evening. Yeah, sure. As you wouldn’t have a million better things to do on evening. As you wouldn’t be tired. As you wouldn’t think about a beer and a good book instead of another boring Excel sheet. Yes, that’s a good idea. Go for it.

2. I’ll die here but I’ll do it. What a consequence! Even if you are tired and ineffective consequence will allow you to... well, at least it’ll allow you to go to bed late. Or maybe, just maybe you’ll just die before you do it. And definitely all those stories you’ve heard from developers who found the bug fix while they were resting or even dreaming are just fiction.

3. Complain. I have wild loads of work. I’m so poor. I just cannot complete that on time. I try, but it surpasses me. At least you moved some pressure from your back. It was so big you just couldn’t work. And now, when everyone has heard you complaining you feel much better. Even if it took 2 hours.

4. Give me more, I’m the hero. You’re cool. And you help everyone. Hey, that’s what heroes do. You’re full anyway so another tiny task won’t do a difference, right? And you build your reputation.

5. Don’t delegate. You want something done well? Do it yourself. Delegating is overrated. You never know when someone screws something up. It’s better if you won’t allow others to do anything with your tasks.

Feel free to mix all of those. The more of them you use the better you support your backlog.

You probably experienced that. Loads of work, limited time and no light at the end of the tunnel. For each thing you do there’s another one or even a couple of them which arrive to your inbox. The Mighty Backlog has taken you under control. Nowhere to run, nowhere to hide.

There are several techniques you can employ to do something with the problem.

1. Do it now day. A last-in-first-out model. You manage each new thing as fast as possible digging deeper to your todo list. Theoretically it shouldn’t work, but practically that’s great solution. You set up your mind to kill each incoming email and magic happens. You go through tasks faster than you’d think. There can be a problem with that approach if a big piece of work arrives but no excuses here. Last in, first out.

2. Begin with smallest ones. Start cleaning with managing the smallest tasks. The list will shrink soon and with less clutter it’ll be much easier to manage the rest. And you won’t need to answer all people who asked you for those little favors when you’ll be able to do it.

3. Follow the flow. That’s hardly controllable, but there are days when you’re on fire. You work more effectively than every day. Try to exploit those days to do the most important things or shorten your backlog.

4. Plan. Make a detailed plan for a several hours which things you’ll work on. One after another. Follow the plan. Make a remorse-list and put in on sight. Cross out each completed task.

5. Turn off disturbers. Messengers, websites, sometimes even email clients. Turn off everything which distracts you and isn’t crucial. Don’t go for a coffee. Don’t engage each discussion you hear.

You can try to mix a couple of those techniques but do it wisely. If you go for a do it now day, don’t try to fix the easiest thing first.

The one general advice is: don’t wait. Try to defeat your backlog as soon as possible. Other way that darn thing will grow and the task will be harder.

I’ve seen a million decisions affecting employees which were made without any consultation with people. Majority of them were made for the sake of employees. You know, like parents who always know the best choice for children without asking them about their opinion. Even when children are in their thirties. And married. And have their own children.

I know you can’t debate with everyone every single decision you make, but sometimes you just go to hit the wall hard with your head just because you don’t feel like asking if your actions make any sense.

I can recall a couple of reporting processes which wouldn’t have been implemented if someone had asked people what they think about the idea and why it is a piece of crap. Most of organizational changes could be at least improved if not avoided if managers were talking with their people. Actually each process which touches employees is vulnerable to that risk.

I don’t say you should run a survey whenever you want to invite some organizational change but asking several persons during informal chant in a kitchen what they think about the idea wouldn’t be a poor choice. What would you think if we implemented that kind of reporting process? What’s your opinion about code review? Would you like to have a chance to rate your colleagues?

Ask. Listen to answers. Reevaluate your ideas.

“Let’s add some function here. It’ll work that way for the first 15 minutes since the service activation and another way later. We’ll have to teach users only one function instead of two.”

And you’ll have your users wandering why the heck that feature works differently each time they use it.

“Let’s put a menu here. User will be able to choose what exactly he wants to do. Menu will appear each time a user enters as it should be possible to choose each option even if the first one will be chosen in a vast majority of cases.”

And you’ll have your users swearing each time they’re choosing the default option as they always do.

Make your users’ life easier. Give them simple unambiguous paths and shortcuts. If you have two different functions give two different buttons, menu options or short-codes to invoke them. If you have one option used much more often give a shortcut by adding another easier method of calling it.

Users like simple operations. If you need to teach users for more than several seconds how to launch your new cool feature it’s too difficult. Note that I’m telling about launching a function, not describing what it does and how it works.

If you ask me, leave ideas as those mentioned above and try to find a way to have each feature, which is extensively used available under one click.

A typical time-span for projects we deliver here in Wind Mobile is about six months. That’s considered rather as an average size when talking about systems for mobile operators. However that’s definitely enough to see significant changes in this competitive business environment between the beginning and the end of the project.

Usually before we finish deployment we get a list of features which are to be ordered just after final acceptance. These are either new ideas which appeared during implementation or features forgotten during initial negotiations or things which appeared not very useful or usable during tests and need to be improved.

A great environment for agilists you would say.

Well, yes indeed. Except of I’m yet to see mobile operator which would agree on that methodology for a typical business project. Quite often it’s hard enough to break even a little step in implementation procedures, not to mention putting a whole thing upside down.

What option you have then?

• Go for agile. At least you can try. With typical business project it can be hard, but for projects which can be classified as R&D it’s easier. I’m lucky enough to work with that kind of approach with at least one of our customer. And for goals we put on our roadmap it works great. Unfortunately in most cases I can say you won’t be allowed to use agile approach with that kind of customers.

• Manage it. You work with one of old-fashioned ways. You have scope, you have schedule and here you go. Each time when new requirement appears you manage it – add to the list, decide whether to implement it or not. And once decision is made you take whatever it brings. Additional effort, retests, changes in other functionalities or... nothing. As far as you decide consciously you shouldn’t cry about it.

• Scope creep. That’s the previous option but left alone without any control. Sure, they will try to put in as much new features as possible. Sure, being a naysayer is unwise but so is the other end of the scale. If you enter to uncontrolled scope creep you won’t reach the goal in fair condition. It’s a difficult decision to set up the best point when you start to reject but a crucial one.

• Be a naysayer. Talking about naysayers... you can always say: “Hey, there’s an agreement and I can’t see even a word about the feature, so you better forget that until we see a signed purchase order.” You’d be surprised how often this approach is used. I’m not sure which scenario is worse – this one or scope creep. When you have a standard answer for every question, most of the time this answer won’t be any good.

It’s always worth to look for the most reasonable way of working with changing requirements. Agile brings very good answer for that, unfortunately its implementation quite often isn’t feasible (that’s subject for another post by the way). But each process which involves a common sense and a bit of analysis to decide individually what to do with new or changed requirement should work well.

I’m curious what your approach in that area is.

Our team was reinforced lately by an experienced project manager. He worked in his previous company with one of our clients. I’d add that our client works in formalized environment where compliance with procedures is (usually) very important, which should limit freedom in project management. The interesting thing is we can confront our experience.

If I had to give one general conclusion I would say that the way the project is run is highly dependent on people, especially project managers, on client side.

Project manager’s strengths and weaknesses have great impact on the whole project. With a great organizer you won’t need to ping them for each delivery you’ve agreed. With a PM with wide technical knowledge most issues can be resolved in small group and there’s no need to check every little thing with specialists. Person who work in the organization for years will know each shortcut and backdoor within procedures and will be able to exploit them. Overloaded project manager won’t push a project very hard as he’s, well, overloaded. Guy who’s not liked much among colleagues will find hard to organize help whenever needed.

Project we compared were run completely different. While general procedures which applied were exactly the same project managers had different profiles. By the way, I guess if we had other guy on the other side we would finish our project later.

On a side note I’m sure the same rule applies when you’re a client and you look at vendor’s project manager.

That’s why it’s so important to know who is on the other side. You want it or not you’ll have to adjust to people you work with. You’ll need to exploit their strengths and mitigate impact of their weaknesses. And I’ve seen enough different types of PMs to believe that depending on people on the other side project implementation can look dramatically different.

Who is on your other side?

Ray White gives a tip for managers:

“Love what you do. And show it.”

I wouldn’t limit it for managers only. No matter if you have to show leadership or expertise or engagement. As far as you like what you do and you’re able to show it to others people will appreciate your efforts. It is true when you’re a leader and you try to fire up your team. It is true when you’re a team member and you look for support from your boss and colleagues.

Scott Berkun comes with another law of management. A true gem:

“It is your fault.”

Whenever you screw something up take the responsibility instead of looking for an excuse. Another time I definitely don’t leave that for managers only. Your colleagues should appreciate your ability to admit your failure. Your bosses should appreciate that too. And of course most of all your team will appreciate when “you take enough bullets for them.”

When I read Ray and Scott I realized once again these are things I look for whenever I recruit. And I do it partially unconsciously. Except of expertise in specific area I want to work with people, who love what they do and are able to admit it’s their fault.

It makes a better team that way.

I hear that question a lot during interviews.

What’s your working hours here?

And my answer is always the same.

Whichever suit you fine.

Of course flexible work-time brings some issues. It will be harder to organize meeting when you have in the team a person who starts at 7am and another who starts at noon if you’re lucky. It can happen that you’ll end up with sleep lovers only and no one would react early in the morning. You won’t predict exactly when your colleagues will be at work.

But these are rather small issues when compared with making people a bit happier. People able to wake up late if they like that. People able to go on errands for themselves during workday whenever they need. You can’t count that in money. It’s hard to verify productivity growth. But making people a happier always works.

There’s one trap here. Flexi hours are often a name for working overtime. Then, well, it’s not so good idea. I prefer to tell honestly: sometimes we do work overtime. It happens. We don’t treat as a normal situation but it happens from time to time. And we don’t call it flexi time.

As far as a deal is fair it is definitely worthwhile. Especially when you work in IT environment where you can find more people who appreciate freedom. If it doesn’t kill your work processes, go for it.

How many times you were in a situation when salespeople told you how to develop software? Or how much time you need to complete an application. Or how easy it is to implement an integration interface.

OK, I have another question. How many times you told salesmen how to sell your software? Or how much they should charge for your professional services. Or how they should talk with the customer.

One of wisest things one of ex-CEOs said was “developers always know better how to sell and salespeople always know better how to develop.” Since then I try to catch myself each time when I tell our friends from sales team how they should do their work. Although I’m not completely successful at that I think my awareness has grown much. As the side effect I’m also more aware when others tell me how we should produce our software.

Anyways, my observations aren’t very optimistic. I can say we generally think we know better how others should work. And we rarely stop to think why the heck we’re spending all our days writing some code in Java instead of selling software if we’re so darn good at that. Or the other way around.

Whichever technique, habit or task you’re trying to invite, be consistent. No matter how poor you are on the beginning consistency will most likely make it work.

It can be new system managing tasks from other departments. Just force yourself to use it always, for every single task you receive. It can be a simple training you try to exercise to learn new things. Just start every day doing that. It can be code review you’re trying to implement in your team. Just have the code reviewed every time you submit it to the repository.

Even when a starting point is far, far away from whatever you’re trying to achieve consistency will give you a chance to succeed. With each day the task will be a bit easier. Just be consistent.

By the way if I consider this blog as a success the only reason is I am consistent with my writing.