So, it’s that time of year again when we reflect on the previous year, what made us happy, what made us sad, how could we change things for the better, how to gear up and be on the positive side of life for the new year etc. Since we live in the world of hashtags, #thingsthatshouldbeleftin2016 has been trending in the past while…appropriately so! This inspired me to think about what I wanted to leave in 2016 from a work and career perspective which then led to thinking about what I wanted to leave in 2016 from a project perspective.
During my career in IT, I have been fortunate enough to work in most of the major roles involved in the project life cycle; development, project management, business analysis and in my most recent project even testing. I wish I could claim this makes me somewhat of an expert in all things IT project related but alas, that would be #nottrue. Though not an expert, I have learnt a great deal by being involved in these various roles. A lot could be said about what makes IT projects successful or not successful and there have been many articles written on this topic.
In my experience, these are some of the major project #thingsthatshouldbeleftin2016: (in fact we should have left these things long before 2016)
Initiating IT projects without proper analysis of the business problem it is aimed to solve: We’ve all heard the expression “failing to plan is planning to fail”. Although planning is the first phase on the project lifecycle, many organisations rush this step and do not put enough focus on analysis or unpacking the problem upfront. Planning may seem to be a waste of time and people tend to rush into implementing so they can have something ‘tangible’ to show for their efforts. However, by putting in a bit more effort or more rigid stage gate requirements, you reduce the risk of merely implementing a system instead of solving the problem.
Under resourcing projects and expecting no impact on delivery and quality: Under estimating resource requirements can be detrimental to project success. It is very important to have the right resources at the right point throughout the project’s lifecycle. Not all resources need to be 100% allocated throughout the project, however, they do need to be allocated and available at certain critical points depending on the function. For example, not having a business analyst available when testing resumes could have a negative impact on testing when requirements need to be clarified.
Involving key stakeholders too late in the process: Buy-in from stakeholders is one of the most important aspects of project success. Even when things are not going well, if stakeholders have been taken along on the solution journey they feel a sense of ownership and responsibility for the success of the project.
Insufficient allocation of testing time: In most projects, I have been involved in, testing is usually the last component to be considered and allocated limited time. As the project schedule gets even tighter, more time may be taken from the testing allocation. As often as this may happen, it is very counter intuitive, why do we sabotage the one stage gate that is put in place to test the solution for real world readiness? By considering testing early in the process – as early as design or requirements gathering, you reduce a lot of uncertainty and risk when actual testing resumes.
There are many more project #thingsthatshouldbeleftin2016 I could think of, but these are the issues that I have noticed occur more frequently. All of this is easier said than done, however, being mindful of the project implementation process and remembering why we are doing each step, would be a step in the right direction.
Would you like to connect with us to discuss a business problem you need assistance with?
Get in touch with us today if you ae looking for the expertise of a niche management consulting firm.
Give us your biggest challenge!
Contact Cathy on (0)21 447 5696 or cathy@analyze.co.za
Nicely put Sivu!