3 tips I use to overcome procrastination

 There are certain activities which you know you should be working at, but still keep pushing it away.

At times, I would complete it, since it is mandatory to do, others get pushed indefinitely. A few of those tasks, may not mean much and is better to die off. But there are a few others, that I know would help me, but still gets postponed.

While going through my diary, the other day, I saw certain books to be read, and activities that are planned every year and are repeated. Reflecting on what could I do better and why are certain things getting postponed, I found the below to be the culprits

Many tasks planned

This is especially true for personal projects. You have many items listed which you know you would not complete entirely. So, if you can complete some, you feel you have achieved the target.

But, after trying to narrow down the list for the past 6 months, it seems that I can provide more focus on the tasks and complete them. It is much easier to track the progress in a skillset after a period of time and see how it aligns to long-term goals.

Feels too big

Some workdays are bad and some worse. And you find that there are some unplanned tasks lined up or some unexpected issues that need to be fixed. It feels like a never-ending loop and you feel overwhelmed.

The advice my previous manager had given for such situations is to "Take a small break from your desk. Come back and then write down the task, split it up as sub-tasks, and then start with the smallest one". It has worked for me. Completing the smallest task gives a sense of control over the situation, which earlier left you paralyzed.

Doing it for the first time

To take on a task, which is not familiar is a bit of a challenge, be it professional or personal. There is a risk of failing, wasted effort, and uncertainty associated with it. To avoid these, you tend to put it off for a better time, that never comes. Or, you keep preparing for it, like collecting more information, read about it and it makes you feel better. But the actual action is still pending.

For such scenarios, it is easier to take action, if you can connect it with something similar done in the past. It may not be from relatable domains, but you can see similarities. The negotiation skills you learn at work may help you deal with kids at home. You have to acknowledge that every endeavor cannot be a success and failure is part of life. Giving up opportunities for the fear of failure is the biggest failure. Try things out small and make changes as you gain more understanding. Don't hesitate to ask for help, many will be there out to help you.

Book Summary - As a Man Thinketh

This book by James Allen outlines the power of one's thoughts and how it could work for us or against us.

Act is the blossom of thought, and joy and suffering are its fruits; thus does a man garner in the sweet and bitter fruitage of his own husbandry. "Thought in the mind hath made us, What noble and Godlike character is not a thing of favour or chance, but is the natural result of continued effort in
right thinking, the effect of long-cherished association with Godlike thoughts.

Man is made or unmade by himself; in the armoury of thought he forges the weapons by which he destroys himself; he also fashions the tools with which he builds for himself heavenly mansions of joy and strength and peace.

Man is buffeted by circumstances so long as he believes himself to be the creature of outside conditions, but when he realizes that he is a creative power and that he may command the hidden soil and seeds of his being out of which circumstances grow, he then becomes the rightful master of himself.

Circumstance does not make the man; it reveals him to himself

Man, therefore, as the lord and master of thought, is the maker of himself the shaper and author of environment... Not what he wishes and prays for does a man get, but what he justly earns. His wishes and prayers are only gratified and answered when they harmonize with his thoughts and actions.

Men are anxious to improve their circumstances, but are unwilling to improve themselves; they, therefore, remain bound.

man is not rightly conditioned until he is a happy, healthy, and prosperous being; and happiness, health, and prosperity are the result of a harmonious adjustment of the inner with the outer, of the man with his surroundings.

UNTIL thought is linked with purpose there is no intelligent accomplishment...man should conceive of a legitimate purpose in his heart, and set out to accomplish it. He should make this purpose the centralizing point of his thoughts.

He should make this purpose his supreme duty and should devote himself to its attainment, not allowing his thoughts to wander away into ephemeral fancies, longings, and imaginings. This is the royal road to self-control and true concentration of thought. Even if he fails again and again to accomplish his purpose (as he necessarily must until weakness is overcome), the strength of character gained will be the measure of his true success, and this will form a new starting-point for future power and triumph.

Thought allied fearlessly to purpose becomes creative force: he who knows this is ready to become something higher and stronger than a mere bundle of wavering thoughts and fluctuating

ALL that a man achieves and all that he fails to achieve is the direct result of his own thoughts.

Your Vision is the promise of what you shall one day be; your Ideal is the prophecy of what you shall at last unveil.

The more tranquil a man becomes, the greater is his success, his influence, his power for good.

Self-control is strength; Right Thought is mastery; Calmness is power. Say unto your heart, "Peace, be still!"

What are functional requirements and how to capture them?

Functional requirement document (FRD) or Functional requirement specification (FRS) is a part of most project. What is covered in a FRD/FRS? FRD would capture all the functional requirements for the system or web application. So, then what is meant by "functional requirement"?

Functional requirement explains the behavior and information the system will manage.  It states on what the system shall do. An example, would be "'My Accounts' section would display the list of all active accounts held by the user."

Functional requirement can be about logical calculations, business rules, audit checking etc. The functional requirement document would also contain the overview and the context of the project.The list of items that can be part of functional requirements is as given

• Business rules
• Calculations or formulas
• Authentication
• Authorization
• Audit trails
• Certifications needs
• Report generation
• Archives/Historical data
• Legal/Compliance requirements
• External Interfaces

The functional requirement document should list the requirements in clear  and concise manner. For better understanding, the document should be structured, with clear headings and sub-headings. It should have the same style pattern and be numbered. Use diagrams, wire-frames and data flow where required. Explain the system and ensure that all the functionalities are captured.

Functional requirements are captured in different templates like FRD, Use Cases or User Stories. A FRD or FRS, would have all the functional requirements in one document in an ordered list. The project overview, system details, assumptions, project scope etc would be part of this document. Each of the details would be captured in sections and sub-sections and length of the document can be 20-40 pages. Use cases are mostly used for website requirement gathering, where each functional requirement is captured as a series of actions performed by user in the system, to achieve a goal. User stories, mainly used in Agile projects, have the syntax as "As the {user}, I can {do something}, so that I {get this result}.

No matter what is the template being used, functional requirement document, serves as the gateway between IT and business users. To avoid any gaps in requirements and to make sure no requirements are dropped half-way through the project, ensure that all stakeholders (IT, business, architects, etc) are part of the review process. This would avoid any delays or increase in cost due to rework. A well reviewed and signed off functional requirement document, ensures that the IT team develops the system as per the business needs.

In addition to the functional requirements, there are also non-functional requirements for a system/application. More about non-functional requirements in next post.

How to write a requirement document?

A good document should satisfy the three C's - Concise, Clear and Complete. It is very true for the requirement document also. When a business analyst writes the requirement document, they may write the document, in a condensed or restrictive language, assuming that the other person would understand. Each user works in their specific business domain or "circle", where there would be certain terms and understanding among the colleagues. When communicating with each other in the department, using this restrictive language would be fine, as both the teams are on the same level of understanding.

BAs are comfortable in their domain and while documenting the requirements, unconsciously the restrictive language might come in the writing. IT team is not from the same domain as the BA and it is not necessary that they understand the implied meaning. Many a time, the defects caught can be traced back to a requirement, that was not clear or complete.

Business Domains 

BA must take conscious effort to make sure that the document is written in the elaborative language. One way to make sure that the requirement is elaborate is to have a review done by a peer from another department. Some examples of restrictive and elaborate requirements are listed

Restrictive	Elaborate
The data has to be backed up once a week	The data has to be backed up on every Saturday at 9pm and two copies has to be saved – one online and one offline
The system must allow users to view account summary	The system must allow users to view their account summary for the past one year
The system must provide summary report on Friday	The system must provide a summary report to the accounts manager on Friday 3pm UCT and it can be viewed from --- section

As can be seen from the examples above, elaborate requirements, ensure that there is no ambiguity and therefore helps IT to design better solutions. 

What are User Stories and Epics?

User Stories are high-level functional requirements, mainly used in Agile projects.
A user story typically has 3 parts-

• AS A - this identifies the user - it could be a general user, for example, the customer browsing the website, or it could be a specific set of users (business class users) or it could even be a system. The user/actor defines WHO wants the requirement.
• WANT - this refers to the action. WHAT is required? For example, I want to cancel the order, I want to open a new account, etc
• SO THAT - this refers to the WHY section, i.e, the advantage or use of the requirement. 

Some examples of user stories are

• The customer can order gift cards online using their credit cards
• As a patient, I should be able to make a reservation for a doctor online, so that I can see the doctor without waiting

User stories are very high-level requirements, that can be used as the starting point to flush out more details of the requirement. User stories are easy to write than use cases and functional requirements and it is typically written by stakeholders or business analysts. 

Good user stories would have the following characteristics - Independent, Negotiable, Valuable, Estimable, Small and Testable.

Epics are larger user stories that can be further broken down into several user stories. Epics are usually lower priority user stories, which when later is taken for development, is examined more closely and divided into several user stories and may be completed in more than one iteration