Artykuł sponsorowany
Is it a need? Is it a wish? Is it someone’s hidden agenda? Or is it a buzzword explaining on the operational level that we have to implement strategic plan or vision? Whether your project is a part of portfolio, program or a standalone one, you should always consider why you are doing it.
The agent of change
Nowadays, steering committees, project boards or sponsors (especially external ones) are expecting more and more from project managers – not only in terms of leadership skills, but also to look beyond project boundaries and to understand business case to its fullest. Project managers should become agents of change. The shift is noticeable even in job descriptions, where business acumen, negotiation, motivation and team building skills while managing people are listed as the desired characteristics of a potential candidate. It might indicate that organizations want people who are business oriented and have well-developed soft skills apart from project management competencies.
Ongoing business case justification
We live in a fast-paced world. The markets are changing constantly, there are lots of disruptors in a connected global network, as well as new frameworks, new laws and rules which are being established almost each year. Using e.g. Toyoda’s 5 Whys, you should drill down into the root cause of a business case. Ideally, it should cover why project is needed and why this solution or approach was chosen. Well, it would be great if you could participate in a business requirements elicitation, which should be a pre-requisite for a business case. Unfortunately, we don’t always have a chance to do that. We have to adapt to the changing world, be flexible and keep our eyes on main business drivers. In other words – we have to focus on a project goal – what business wants to achieve and how we can deliver that. According to the project management standards, we should continuously reflect on ongoing business case validation and continued business justification. By doing so, project team should be encouraged to continuously assess if they are on the right track to achieve the expected result of the project, as well as to explain possible trade-offs and provide meaningful data to make informed decisions – regardless if it is on project’s level or higher.
Where you want to be next
I would like to share with you some ideas on how to adapt to the ever-changing business drivers for ongoing projects. There are thousands of reasons why projects are launched. Nevertheless, the assumption that ‘the majority of these projects are kicked off because of the financial reasons’ seems to be plausible. Let’s face it, most companies are established to make money and focus on good ROI or NPV. There is not much of a difference between making cost savings, looking for a higher revenue and profit or avoiding fines and losses initiatives. What matters is to ponder about your surroundings, understand limitations of given enterprise and its environmental factors, as well as to have a big picture of the organizational process assets in your mind. Try to do your best to get to know your stakeholders and their needs, and then adjust the best measures you can use to deliver the project goal. Aforementioned approach helps to provide insights for proper alignment with business, implement correcting actions quicker and manage risks diligently. When you know where you are, it is easier to imagine where you want to be next.
Pure waterfall projects
I think it is safe to say that in IT world there are no longer pure waterfall projects. By pure waterfall I mean the situation when all requirements and all technical documentation have been gathered and prepared up-front before any development work has started. Then, the sponsor kicks off the project and gets a working product or solution only by the very end of the project. There are certain attributes of being agile. In a changing environment, which we face every day, such attributes might be crucial to deliver the best business value to your stakeholders. I don’t want to focus on that aspect now, as there are many great books and articles covering agile from fundamentals to the expert level. My takeaway here is to think about your contract, project charter, project brief, work package or statement of work and how flexible you (and your organization) are. Do you tend to implement many amendments to the scope? Are your procurement processes lengthy and cumbersome? If the answer is yes and if you anticipate lots of changes as project evolves, then you should definitely consider hybrid approach (mixed waterfall with agile). In practice, it can be a fixed priced contract with given budget (or a cap), schedule, high level quality expectations and high level scope which will be clarified and mutually agreed within timeboxed periods. On the other hand, it might be less difficult to go with full agile and start incremental delivery contracts like a Minimum Viable Product approach or a test phase and re-evaluate at specific project milestones.
Stakeholder expectations
As the project continues, project managers should reflect on the delivered results to assess project success and validate business goals. Furthermore, project can finish on schedule, meet quality expectations, even below the budget – with reserves untouched, and still fail to deliver business value. Imagine you and your team have just released bespoke software to do some calculations on end user’s machines. You failed to notice and escalate that there is a newer framework on the market, enabling end users to use cloud computing. Your sponsor’s competitors didn’t miss that chance and have implemented this framework in their software. The end products – yours and your competitors’ seem to be similar, with one significant difference – their solution is up to 50% faster. It is obvious that your project’s business value has diminished and sponsor might have to change pricing policy in order to gain any market share. If you don’t understand the business driver, how can you foster provided resources, achieve Tuckman’s 4th stage of team development and satisfy the sponsor? Similarly, it is vital to properly manage stakeholder expectations, especially not to over commit and then not deliver.
Project success factors
There are no ‘silver bullets’ to ensure that your project will be successful, however some actions might be helpful, such as: building strong relationships with your sponsor or project board and setting up S.M.A.R.T. objectives (and key results). I can’t stress that enough that committed people are the most important driver of project success because projects are about people, their ability to cooperate and create synergy. Looking at this problem from a different angle, MoSCoW or any other prioritization technique, should be your friend to stay on the top of turnaround stakeholders needs. What is more, forecasting in the project plan quality gates or decision milestones, should be a great exercise to validate progress and justify the business case. It is strongly recommended to check upon your stakeholders after project closure once in a while and show your eagerness to assess project’s outcomes and confirm benefits. Findings of that will be a great input for a lessons learned and possibly will help to improve your projects in the future.
Experienced IT Project Manager with a demonstrated history of working in finance and IT industry. Delivered complicated and complex projects in waterfall, SAFe and hybrid waterfall-agile frameworks while remotely managing teams across the globe. Currently managing e-Commerce fixed-priced projects at SoftServe. Always eager to develop himself further, gain knowledge and experience. PMI-PMP®, PMI-ACP®, PRINCE2® Practitioner, AgilePM® Practitioner, ITIL®v3 Foundation, WSB:Six Sigma Yellow Belt holder.