What I learned in some project life cycle phases

In the last months I’ve participated in some IT projects since initiation phase. Although the projects were different, there were actions in common (‘patterns’) that helped their construction and I believe, they can be equally applied on future projects.

In this post, I will talk about those actions I learned on the following phases of a project’s lifecycle: planning, development and testing. Pointing out on each phase, actions with their description or justification.

Please note that these are not the things you must do to succeed, of course one should adapt to the circumstances of your company, like a methodology or the environmental enterprise factors when your team and you are building an IT project. Thus, my intention here is to share what I have seen in practice.

Planning

Get as much information as you can

In this phase, one has the opportunity to gather requirements, defining processes, meeting the key users, get all the information in order to set baselines such as: a schedule, a definition of a project’s scope or budget. It’s valid to learn as much as you can of the project.

So start by questioning your users, search for allies/stakeholders that are willing to explain you what they expect from the project, prepare your lists of questions or doubts, schedule meetings…all of these will help you to make one clear scope for all the stakeholders and reduce the project uncertainty.

Establish deadlines and risks.

Apart from creating the project’s baselines, it is necessary to establish deadlines in which you point out commitments like delivery dates (for example the delivery of your project plan to your stakeholders). Mention the risks and impacts of not accomplish the commitments and so on.

Make sure the stakeholders are aware of those risks (I’ll take the opportunity here just to mention one more important reason of why your e-mails needs to be as specific and clear as possible)

Search for a unique channel of communication

In order to avoid misunderstandings between the key players, one person should orchestrate the communication to the stakeholders and the development team. Generally this player is one customer member.

Development and monitoring

Search and solve the remaining uncertainties (if any)

Once the project’s scope is already specified, it is time to share the documentation like functional specification to the developers. It is normal some questions arise, but they should be minimal…after all there was an analysis and design phase before.

Keep communicating the uncertainties back and forth to the stakeholders and of course, don’t forget to mention commitments or plans of how to solve them.

Testing

Detect failures or requirements with your functional specification

In UAT, it may be the opportunity to detect bugs in the software or to develop new requirements. This might happen when the user had a general idea

about a feature and defines it so. Once he tests the product or feature, the user may realize that there are more features or functionalities missing.

Whatever is the case, this finding needs to be analyzed, compared against your functional specification (such as the SRS) and classified as a requirement, a bug or an issue not applicable to the project. If it’s a change in the scope like a new requirement, it has to be managed by a change control process stating the change requests, the stakeholder’s authorization and clear knowledge of the impacts of the change before implementing it.

When monitoring the testing phase, you may see that the users or testers don’t know exactly the behaviour of software developed. The behaviour might be reported as a bug or a failure without making the proper research. Unfortunately, information like that or misunderstandings may impact in a negative way the image of your product.

It is necessary to play an active rol and help to classify things correctly.

Originally published at www.thekairuz.com on September 1, 2017.