Stress Management

A LECTURER, WHEN EXPLAINING STRESS MANAGEMENT TO AN AUDIENCE, RAISED A GLASS OF WATER AND ASKED "HOW HEAVY IS THIS GLASS OF WATER?" ANSWERS CALLED OUT RANGED FROM 20G TO 500G. THE LECTURER REPLIED, "THE ABSOLUTE WEIGHT DOESN'T MATTER. IT DEPENDS ON HOW LONG YOU TRY TO HOLD IT."

"IF I HOLD IT FOR A MINUTE, THAT'S NOT A PROBLEM. IF I HOLD IT FOR AN
HOUR, I'LL HAVE AN ACHE IN MY RIGHT ARM. IF I HOLD IT FOR A DAY, YOU WILL
HAVE TO CALL AN AMBULANCE. IN EACH CASE, IT'S THE SAME WEIGHT, BUT THE
LONGER I HOLD IT, THE HEAVIER IT BECOMES."

HE CONTINUED, "AND THAT'S THE WAY IT IS WITH STRESS MANAGEMENT. IF WE CARRY OUR BURDENS ALL THE TIME, SOONER OR LATER, AS THE BURDEN BECOMES INCREASINGLY HEAVY, WE WON'T BE ABLE TO CARRY ON. AS WITH THE GLASS OF WATER, YOU HAVE TO PUT IT DOWN FOR A WHILE AND REST BEFORE HOLDING IT AGAIN. WHEN WE'RE REFRESHED, WE CAN CARRY ON WITH THE BURDEN." "SO BEFORE YOU RETURN HOME TONIGHT, PUT THE BURDEN OF WORK/TASK DOWN. DON'T CARRY IT HOME. YOU CAN PICK IT UP TOMORROW. WHATEVER BURDENS YOU'RE CARRYING NOW, LET THEM DOWN FOR A MOMENT IF YOU CAN." "RELAX; PICK THEM UP LATER AFTER YOU'VE RESTED. LIFE IS SHORT. ENJOY IT!

Management lesson - Learning From Lessons - Ten Steps

I got this from one of my colleagues and I found it very useful. I follow them in my project and focus on the mistakes that could have been prevented and appreciate the good things in the project.

Learning lessons from past failures is an important source of progress.

Managers should plan a formal 'lessons learned' session during the closing phase.

Many organizations use the term "lessons learned" to describe the way in which they avoid repeating mistakes, or ensure that they build on past successes, yet a lesson can only be applied if it has been successfully identified, and captured first.

The next time you make a mistake, write it down. No matter how trivial the problem might be, document the error (as well as the process required to remedy the mistake, and the correct steps that are to be taken instead). Just as it's frustrating to see your favorite Cricket team make the same mistakes over and over without learning from them, project managers are equally vulnerable to an unending repetition of errors. What makes it acutely painful is the loss that the project, its members and the organization, suffers. From time lost to unnecessary duplication of effort (which erodes morale) to financial losses from wasting time and resources, everyone loses.

By something as simple as maintaining a managers' log that documents all errors, such losses can be avoided. If this log is updated and shared between all project managers at all times, we have a unique opportunity for project managers to learn from mistakes (of others and their own).

Ten key steps to facilitating a "lessons learned" review.

1 Call the meeting. Hold a face-to-face meeting as soon as you can after the project ends, within weeks rather than months.

2 Invite the right people. The project leader needs to attend, as do key members of the project team. If a similar project is already underway, then there is great value in the new project team attending - a "customer" for the knowledge

3 Appoint a facilitator. Identify a facilitator who was not closely involved in the project. The facilitator should be someone who can ask questions from an independent, but non-threatening standpoint. This isn't an audit, it's an investment!

4 Revisit the objectives and deliverables of the project. Ask "what did we set out to do?" and "what did we achieve?"

5 Go through the project step by step. Revisit the project plan and identify any deviation from plan. Where the delays and what were went ahead of schedule? What changed and why?

6 Ask what went well?? Ask "what were the successful steps towards achieving your objective?" and "what went really well in the project?"

Ask a "why?" question several times. This is vital, and will get you to the root of the reason. Don't take the initial response at face value. Often people don't even realize what the underlying reason behind a success or failure is. Your role may involve guiding them on a voyage of discovery.

7 Find out why these aspects went well, and express the learning as advice or guidelines for the future. This is a key point. Try to avoid expressing lessons learned in a passive, past tense, such as: "Project Foxtrot completed ahead of schedule because the project team remained in-tact throughout the design and execution stages".

The lesson will be far more accessible to others if it is expressed as:

"On time-critical projects, ensure that the project team remains consistent throughout the design and execution stages of the project. This will eliminate any learning-curve issues due to the take-on of new staff".

As the facilitator, acknowledge feelings and press for the facts. Ask "what repeatable, successful processes did we use and how could we ensure future projects go just as well, or even better?"

8 Ask "what could have gone better?" Ask "what were the aspects that stopped you delivering even more?" Identify the stumbling blocks and pitfalls, so they can be avoided in future by asking "what would your advice be to future project teams, based on your experiences here?"

9 Ensure that participants leave with their feelings acknowledged. Ask for "Marks out of ten" and "What would make it a ten for you?" to access residual issues.

10 Record the meeting. Use quotes to express the depth of feeling. Express the recommendations as clearly, measurably and unambiguously as possible, using the guideline format explained in point 7. Ensure that you circulate the write-up around the participants for comment, and permission to use specific quotes before sharing more widely.

Conclusion

Identifying and recording lessons learned is fairly straightforward process, given the simple set of steps above and a measure of facilitation skills. The benefits come from ensuring that the lessons are actually applied - which is another story!

Requirements gathering technique

There have been lot of templates and processes defined as requirements gathering techniques. From the beginning of the project, we will need lot of clarifications on the customer's business requirements. It is always good to log them in a spread sheet. This way you can easily track how many of the items are closed, open and pending and also classify them based on priority, dates, etc. I have predominantly used them right from the project initiation phase and found lot of benefits using the same. This issue log serves as a reference document on the important requirements clarification and serves as a proof for your work. This also works very well in an onsite offshore model. I have given below a snapshot of fields that can be good candidates in the issue log. You can add/modify/delete fields based on your project requirements.

• Date
• Closed Date/ Resolved Date
  
• Priority
• Assigned
• Type (can have values like requirements, design, etc)
  
• Status
• Description

Cosmic FFP certification

For those that are thinking about certification on estimation, we have cosmic FFP certification other than IFPUG certification. In fact, there are two more certification for estimating the software size.

Cosmic FFP(Full Function Points) claim that they are much better and advanced than IFPUG. As an individual, I see the advantage in few important things like the certification for COSMIC is very less expensive compared to IFPUG and also that this certification never expires. For the version of the exam that you take, it will be always valid.

It is an open book certification and the materials are also available in COSMIC website. All the best!

Lack of Formal Reviews at work

Everyone feels under time pressure. It is a general misconception that following Agile Methodology in the project life cycle means that there should not be any documentation and they resist doing the same. The truth is that Agile always says that there can be a reasonable amount of documentation and not too many unwanted documents. For that matter, even the traditional models insist that everything towards the process and no document is unnecessary.

If a person creates unnecessary documents then it means that he has not understood processes rightly. If reviews do not happen then there is a risk that errors are hiding within the code or work that has been done. It is a tendency to blame it on time constraint especially when the project has a tough grueling deadline.

Having said that it is better to review the work product in any kind of software development methodology rather than doing rework many times which wastes a lot of time. If the work is not reviewed, the individual may think that he is on the right track. In order to ensure that the review takes place, we can get to the micro level of the past work done or current work being done and bring out the review defects and insist the team that it is important to follow these processes to ensure that we eliminate bugs. So this will help the team to realize the importance of review and the product has added quality.

CFPS certification

Function point estimation is the most accurate way of estimating a software product. Each requirement is considered to be a set of functions and hence they are counted as function points. I will explicate more about FP in my future posts. This post is to mainly let you all know that there is a group called International Function Point Users Group (IFPUG) that conducts CFPS (Certified Function Point Specialist) exam.

You can take that exam and become a certified function point count expert. The certification is valid for 3 years and are allowed two extensions after that. Once the extension is over, you need to retake the examination. It is also one of the toughest exams like PMP, etc.

Software estimation methodologies and models

There are many ways to estimate software. According to the authors Linda M Laird and Carol Brennan of Software measurement and estimation, they can be categorized into the following:

• Expert opinion
• Using benchmark data
• Analogy
• Proxy points
• Custom models
• Algorithmic models

I will be delving in to the famous estimation techniques in my future posts. So check on this one.