The Project, at its core is the problem we are tasked to solve. Regardless on the approach on how it is completed: Scrum, Waterfall, Iterative, etc., there are key project dynamics that must be addressed at all times and they are what I call the “The Five P’s or 5 P’s. I know it’s cheesy… but simple mnemonics makes thing easier to remember!
The Five P’s are: Project, Plan, People, Personality and Politics.
They are the dynamics of the project since they constantly change, they affect one another, and they are crucial for the delivery team to address if they want to be successful. One of the benefits of an agile practice such as Scrum is it makes it easier to adapt and execute the solutions in a consistent and iterative manner. This is primarily because Scrum in essence is a mixture of well-defined process but with an open interpretation on its execution. This mixture of flexibility and inflexibility combined with its simplicity is what makes Scrum one of the most recognized and preferred agile methodologies.
Project – Either in terms of project scope, length, deliveries, or anything in between this something that will change to some degree in course of the engagement. Since much the changes affect greatly the overall satisfaction of the customer (which should be the ultimate goal of any project) there are few things that should be done as much as possible:
- Make sure to have an open communication with everyone in the team.
For example: During one of the sprints in the project we implemented a piece of functionality that was later discovered wasn’t necessarily needed. It required another sprint to rectify the changes. If proper communications were done mistakes would’ve been avoided and we would’ve not wasted precious sprint cycles.The lesson: Communication, communication, communication.
- Always set the right expectation to the customers by being transparent as much as possible.
For example:Our customer had a lot of features they wanted to include in the sites. Internally, everyone had doubts on being able to achieve this but we weren’t being as transparent as we should be. Halfway through the project we’ve informed them that we need to start cutting down some of the items in the backlog. Obviously, that didn’t go quite too well since they were caught off-guard. If we’ve initially set the proper expectation when the project started and informed them that halfway through the project we will assess the team’s average velocity and based on that detail we will start defining the minimum viable product then it would’ve never been an issue.The lesson: Clients should never expect the unexpected.
- Everyone must take ownership and it’s essential that key team members (Product Owners, Scrum Masters, Technical Lead/Architect & Project Managers) must make decision regardless on whether it’s perfect or not. The longer the decision and ownership of the action items are postponed the worst it gets. This is perhaps one of the most important factors in any project.
For example: Throughout the Sprints our offshore technical lead always made key decision when implementation details weren’t as clear. At times, it may not have been the perfect decision since in some cases it is overturned by our main technical lead. However in most cases the decision is correct and it made the project much more efficient regardless of the time-zone difference.
The lesson: An imperfect man, making an imperfect decision, with perfect timing is one of the keys to success.
Plan – There is no such thing as a perfect plan, if there is, it is written by a clairvoyant. Also, in any project there’ll be detours and roadblocks. If there is no plan to guide the project then it is next to impossible to know where you’re at and where you want to be. This is almost a given in any project so this shouldn’t be a surprise to anyone.
For example: Our TSC project was plan out to start with a full team on Sprint 1, that happened only during Sprint 7 almost halfway through the project. However, because we had a plan in case wherein the team is still not in full capacity we were able to adjust and focus the first few sprints on the core content of the site.
The lesson: Always have a plan; good, bad, or backup, have a plan.
People – The right people in the right role in a project, is as similar as having the right gear in the right position in an old-fashion clock. The clock ticks more in-tune when things are well positioned and tuned. Resourcing any project is quite a difficult task however skimping the vetting process and placing them in wrong role is a sure way of causing unnecessary drag.
For example: One of the positions we tried to fill in in our project is the Migration Team that requires experience in CQ and Java. However, much to our dismay instead of getting developers we were forced to use business analyst that doesn’t have any development experience at all. Our main migration lead tried to teach them but it caused unnecessary drag to him that could’ve been avoided. Eventually, we decided to move the business analysts as the Migration QA Team and use some of our CQ developers to fill in the need in the Migration Dev Team. It worked, not perfect but better. The business analysts were able to adapt to their QA roles much better than forcing them as developers.
The lesson: Project resourcing is a puzzle; it is not meant to be difficult, you just find the right piece and put it in the right place and you’ll get a better picture.
Personality – By nature we all have different personalities. It is part of what makes the project “fun”. There will always be some sort personality clash in some form or another whether it is with a client or within the internal team. As adults, but more importantly as professionals, the only thing that we can do is respect and understood each and everyone in the team. It might seem quite inconsequential, however it is important to recognize it since it affects the overall morale of the team.
For example: In our TSC project, the main tech-lead in the client almost always hijacks any discussion and questions most of the decisions that the development team has made. We understand that it is his job to be the devil’s advocate since he is the tech-lead but most of the time the extent of the questioning borders the line of just being a pain in the you-know-what. For a while, we try to argue but it is just who he is. We accepted the fact that it is his personality and its just one of the many factors of the project.
The lesson: Everyone has a personality including you – accept it.
Politics – In the pursuit of life, liberty and happiness, politics is the necessary evil. It is there no matter how invisible it might seem. It can’t be avoided in any project and it become more apparent when sound decisions are not being made.
For example: One of the few things that we tried to push back to our client is using a 3rd-party tool to assist our content migration. We told them that given with the timeframe it makes it more time consuming for the Dev Team to learn a new product rather than just writing a Java program to do the migration. However, because politics can’t be avoided such that the main tech-lead in the client had convinced the upper management that the migration tool makes the whole migration much faster we were force to use it despite our best efforts.
The lesson: Politics are not just for politicians – unfortunately.
The project dynamics I’ve discussed will always be there. Ignoring them is not an option. Everyone in the delivery team (not just the key stakeholders) must recognize, adapt and provide a timely/appropriate response to each of them. Fortunately, Scrum is perhaps one of the best solutions to address this problem.