Evaluation as a catalyst in the growth of a project

vækst finalIntroduction

Evaluation is a very used expression, which we use all the time in working situations in connection with the solution of a task or project.

The purpose of evaluation is to accumulate the experience you have done, so successes can be repeated and mistakes can be avoided in future projects. The focal point of the evaluation is to ensure that the people involved easily can take benefit from the evaluation process. They will recognize and make it particularly important to focus on and ensure control and learning in the project. The concern regarding control of resources and its optimum allocation in a project, in the context of learning, is that it is essential to gain complete certainty that you are on the right path. In case of conflicts between the people involved in the project – evaluation helps to adjust the process itself.

 

Problem

As a professional IT project manager, I gained experience from large and complex organizations and have seen their limited acceptance in the use of evaluation methods. Here I have seen statements such as “The evaluations cost time, money and let us choose a supplier we already know”. ”Therefore there is no need to spend time to run a comprehensive evaluation process”. Here it turns out that some outcome from projects has a decisive impact on the company’s bottom line and their market share compared to their competitors.

Is it necessary to evaluate?

Experience shows that there definitely is a need for evaluation during and after project completion. Without evaluation, it can very easily go wrong economically for the company. In the beginning of the project it is crucial to evaluate the criteria of gain, what the gain should be and it must be defined in the requirements specification. It is legally binding and determines what vendor shall provide for the money. It is important to involve customers or users of the evaluation process during project development. First of all it is important for the involved people to know if their money and support has been used sensibly or not. Secondly their frustrations over the failures of the project during the research/developmental phase can be used constructively and can contribute to a lot of learning for the future projects.

One solution to the problem can be a so-called agile method for developing both infrastructure and research/developmental projects in private and public IT companies.

 

Solution

Using the agile management

The approach is to work in small iterations of 2-4 weeks duration and after each iteration the finished product is shown. It gives abundant opportunities for people involved (customers, supplier and the project team) to initiate changes as required.

A lot of positive and negative assessments will be committed in all projects. To be successful, and create a positive experience in an efficient way, you need the feedback on the choices being taken. Feedback about the choices made during the project, can easily and efficiently be visualized by using the starfish method.

The Starfish method used during the Sprint Retrospective

The article is only based on SCRUM Sprint Retrospective, and not the entire SCRUM method. Retrospective is one of the important project meetings at the end of each sprint. Here are some of the most important issues to consider and discuss during each sprint.

  • Keep doing: Is a good starting point for team members to focus on typically all the good things that they liked about the project.
  • More of: Is another type of focus that helps further refine or highlight practices, achievement, for an instance, that the team members might want to try more, and are not necessarily taken full advantage of.
  • Start doing: Is a great opportunity for team members to suggest new things to try because of things that may not have gone so well or just for simply keeping things dynamic and fun.
  • Stop doing: Obviously for things that are not very helpful to development practices or not adding much value.
  • Less of: Helps to focus on practices that might need a bit more refining or actions that were simply not helpful in the current circumstance.

 

Screen Shot 2017-05-08 at 16.32.22This method has been used in connection with a public sector customer project.

Experience has shown that there is more room for learning by involving people. Getting people to write on the “yellow note” and then post-it under the group area in the starfish method is also a great visual way to evaluate health in the project. It forces human capital to think creatively and act upon it, Instead of saying things that are not worked out thoroughly. The reason being; saying something verbally is much easier, compared to writing something down on a yellow note.

In several projects, I have used the methodology for both development and infrastructure projects from the public and private sectors. Here I have achieved more excellent results in project evaluations by using the method in Sprint Retrospective. In addition, the results of evaluations have continually contributed to strengthening change processes by sharing insights and results with the customer, supplier, project team and other stakeholders who adapted their activities.

The method is universal and can be used in all aspects of a project. It is highly recommended to use the method after achievement of a milestone in the project and in consultation with all stakeholders/ participants. It informs the participant about what works and that which does not. In this way they will get a better insight and understanding of the results they have achieved. This will make it possible to introduce new ideas by providing constructive feedback.

I would definitely recommend using the method in Scrum Retrospective when you need a quick and sensible evaluation here and now.

prediction_cat_by_sebreg

Management estimate times pi gets it right

Introduction

Estimation is one of the essential parameters that are crucial to whether a project is a success or failure. This is because the error in estimation is expressed as an underestimation or overestimation and is therefore a major problem for the company. Underestimation can be financially costly and overestimation in tender processes may result in that the company does not get the tender.

Estimation-methods are used leniently in most IT companies. The largest and most important reason is that estimation is not always performed by professionals. The estimation is performed by all business functions from the senior management, chief consultants and developers. Despite the fact that a reliable result often requires preparation and composition of various specialists and their skills.

Problem

As a project-manager I have worked with many complex IT-projects. I have experienced on several occasions that the management has been a little too “trigger-happy” when applying estimation.

The management issue
Most managers often lack the necessary skills, expertise and experience to make qualified estimates. This is where the fundamental problem arises. The vast majority of managers underestimate often as they perceive estimate as a negotiating process, where time is the greatest sacrifice. For them it is about informing the customer about the price of the product, which in any case shall not exceed the asking price. If this is the case, then they will most likely select a different supplier. There are some customers who make a claim for getting an early estimate. That is perfectly acceptable, and there should be room for this, as long as there is a broad consensus about the fundamentals with the client about the initial rough estimates.

Experience shows that developers involved in the work are rarely taken seriously. The developers will be blamed when the deadline is exceeded due to erroneous estimates. Because management sets expectations for a quick “guesstimate” and are not willing to pay the costs to implement a real estimation. Furthermore, there are challenges with task-descriptions which may seem ambiguous, which obviously lead estimates into the directions of east and west. It is typically caused by “scope creep” and imprecisely worded requirements which must be improved and that is also part of the problem.
Thus, I believe that it is a problem in management, as they often tackle the estimation process very simplistically.

Solution

How to obtain a more accurate estimation
All these uncertainties and other much more difficult issues can easily be estimated more accurately, but it requires some compromise between management and specialists.

  • Management must fundamentally recognize professionals and their skills. This makes it possible for professionals to get a feeling of the obligation to carry out their work in good faith, accommodating and meeting the expectations of the management. Management must be inquisitive, show interest and engage in dialogue to find out where the complexity lies in the task. It can be because they misunderstand each other regarding the scope or the requirement specifications are not clear.
  • Cooperation increases dividends. Get several different developers with relevant knowledge to provide input and thus achieve a more accurate estimation. We have learned about the use of Scrum poker in the agile world.
  • It is important in the project to identify preconditions by dividing the project into independent activities with the help of the Work Breakdown Structure (project into phases, deliverables and work packages). It is very important for the project and makes it easier for developers to meet the estimation.
  • Diversity in the estimation process is important in order to have different inputs on various project activities. The project managers, Scrum master or facilitators are also responsible for variation in inputs about the estimation since different specialists look different on the assignment.
  • In the initial phase, it is essential to devote time for the project and steering committee meetings, as well as time for design, test and access to the right tools to test persons. Additionally, it is a good idea to set aside time for risks and unforeseen events.

 

It is just a matter of finding the correct methods. I have been involved in projects and have developed a checklist in order to make estimation easy. Here I have learned that the checklist can contribute significant improvements in the estimation process and it shows that the management should consider the following questions in the checklist, before the release of the estimation to the customer. The customer always learns and remembers the first estimate and often it is difficult to change the estimates along the way.

Screen Shot 2017-03-31 at 10.42.25

This checklist serves as a friendly reminder whether if the following benchmarks have been considered your estimate and also works as a support the process of estimation in a given project.

The checklist is universal and can go hand in hand with all estimation methods such as Expert Method and Planning Poker also called Scrum Poker. But I would definitely recommend using the checklist in the start-up phase of customer offers or projects. This must be done in consultation with project stakeholders as well as customers, suppliers, etc. They will gain better insight and understanding of the initial rough estimates. That is not said that you should make estimations during a meeting with customers or external parties before it is consulted with others in the organization.

/ Zubir Shah, Professional project manager

Three ways to avoid null in object oriented languages (Java)

Introduction

The most common line of code that I’ve seen must be:

It’s purpose is usually to avoid the most common exception that I’ve seen thrown in runtime, NullPointerException.

Overview

Null checks are a necessity sometimes but when I see pervasive null checks I consider them being a code smell. I can justify null checks on what I call the “end-points” of software. Let’s say that I am building a simple web-service using some business logic and a database. I find it appropriate to have null checks when receiving external requests to my service and when working with my database. Null checks in the business layer are pointless since that’s already been done.*

* Only applies to code you own. A map that can return null will always need a null check.

Continue reading