How to lose a project in 5 ways and how consultants, admins and end users can avoid these issues, Jasmine Ashley

Editor's Notes

• #3: We have all been a part of a project at some point in our lives. From pitching a tent at camp to planning a birthday party. Returning a ring as part of a fellowship with hobbits and wizards in middle earth to a salesforce CRM implementation phase 1 roll out. During these projects we have consciously or subconsciously done these 5 things well or not so well. We get to the end of a project and and have felt good about what has been achieved or realised that we could have done some things better. How many customers have felt a little jaded or lost on the whole project process and thought I wish I had known a little more before we started. If everyone, consultants, sponsors, end users are aware of these 5 ways to lose and project we can WIN them, achieve our goals and maintain the salesforce Ohana.
• #4: Projects vary from 5 days to 5 years and we hear the terms AGILE and WATERFALL and PSEUDO AGILE as the applied methodology to try determine how we will conduct ourselves and execute the cycle. No matter what way you decide to do the project you will and you have covered these steps. 5 ways to lose a project touch on every single one of these stages. Some people may not be involved in the early stages. In fact I can tell you most certainly not everyone is included in all the stages which is why it is so important to know them and know where you are when you are part of a project. If you try to analyse and design the solution when the entire project is reached the maintenance stage you may well be a bit lost or disappointed when you find out what you wanted wasn’t built the way you wanted it to be.
• #5: What makes a successful project? Depends on who you are asking but these are the high level signals of success that I keep in mind while I am in a project. If we all define them and agree them we are all working in the same direction. The concept of one team can seem hard but the goal is to work as one unit to achieve an end result. Much like your own personal goals a project has its over all goals and targets to keep everyone on the same pathway. For the consultant: best practice is configuration over code. If we all have this in mind then I as a consultant am not going to go rouge and start making triggers over process builder to hand work off. For the customer: An improvement of what we have, you have selected a new solution not to recreate a copy of the current systems and processes you have. Keeping an open mind to the slightly different can be difficult but also rewarding.
• #6: The SCOPE triangle is a project management model that really nails it. Circulating since the 1950s Quality is sacrificed if you soul focus is to save money and do it the fastest time ever. Like all models it is a guide, putting more money and resources into something can slow down time and the quality of the work if you have too many people. Those at the top focused on saving on one of these key areas create tension and pressure at every level of the project This model is not only for consultants but for clients and end users too! A project goes over time and over cost then your budgets are slashed for BAU, you aren't able to do your day job while this project drags out. A loss is having to sacrifice something in order to get it across the line. You still get an end product/ solution but you are left with a bitter taste A success is balancing right in the middle of this triangle
• #7: Projects are done in teams, there is always a team. You may think you are the only person who is doing the work but who you are doing the work for is in the team, who they are working for is in the team and who ever you ask for help is part of the team! For this presentation I have created illustrations to represent the different losses and outcomes you can have when we are working together. These are a visual representation of what can go wrong. This is project Tree house! And this is the team that will be working together to achieve this presented end result. While I am talking through each of the ways to lose a project I will be sharing examples of my experiences and observations. It will be interesting to see who else has had similar experiences as myself, or even better who has worked out ways of improving these experiences. So please come and speak to me after this presentation if you want to share!
• #8: These are the 5 ways to lose a project ! They still have some function but it is not the treehouse we had on the previous slide. This is the journey we will take together. Nostalgic or Insightful this is my interpretation of how project tree house can really go wrong. Roles, Communication, Tools, Testing and Documentation make up the foundation of our project. When one or more is sacrificed we don’t get the expected results. We will work through each – you will see these images again shortly.
• #9: First up – Roles! Who is doing what? When I first started consulting I knew what my role was and I would happily ignore those around me and just truck on. If I didn’t know something I had a senior to talk to and they would fix it. This was a mistake ! Because when that senior was not there – I wouldn't’t have a clue who I was supposed to consult. I would make a call myself or WORSE do nothing until the senior returned. Roles are so important as the first step because they are the directory of who is responsible for what. Who do you escalate to? Is this person giving me work that is relevant to my role and outputs ? This person has just said they approve the requirement – are they the person who signs everything off? ownership respect and availability. Diversity in a project is supported. Raise your hand to support. Raise your hand to ask for help. Not only do we have roles within a project but people have their roles outside of a project too. School pick ups, appointments, part time. Respecting the people you work with and understanding they may be working different hours or have multiple responsibilities.
• #10: Until recently it dawned on me that – I work on projects every other day. I have clients and customers have never participated in a salesforce implementation project before this very slide is presented to them. Its project kick off - we talk about the delegation of roles how important they are – people raise there hands and take a role maybe 2 and I can say I have not looked at the slide or the assignments again. Understandably not everyone knows what the role means or they do, but their interpretation of the role, the responsibilities and time that it will take them to do it is very different to another member of the team. In the past, I have put my hand up to cover people in my team for a short time believing that it would be just sending a few emails and organising meetings. Only to realise their role has taken up my entire day and I haven't had a chance to configure a single thing. I have had super star clients that have taken on multiple roles within a project because they were the only person with all the knowledge of the company. Burn out and take sick leave for the go live. No one else has been able to sign off the work until their return. Each person takes a single role to ensure that all responsibilities are being met. Each person understands that role Each person has someone to delegate full control to if absent. ATTEND meetings, have buy in, and its difficult to do this when you have a company to run.
• #11: Unclear roles at any level of a project will delay time! Throughout a project roles should be revisited. If someone is not fulfilling their role it should be escalated sooner rather than later. Either someone new has joined, someone has been delegated a new role or someone is on leave. It helps keep people accountable and reduces the gaps in which tasks and escalations can fall when trying to achieve in a project. When I feel that my role is unclear, I make a point to take a step back and go over my tasks and responsibilities. This leads nicely on to the next point – In order to understand roles we need to be able to communicate!!
• #12: Communication is key within the project - regular planning, discussion, open floor for those who have found something that helped, something that is blocking and possibly something that is cool to add! (if time permits) Outside of the project communication is as important. Change management. Whose building this. Who’s invested in this. Who’s signing this off. Who’s benefiting from this. If you don’t tell people what you are doing they may throw a spanner in the works Example - If I assume that I need to build a complex flow with 25 different outputs for the customer but I don’t ask them. I may end up spending more time than required building out the best flow I have ever made in my life. Only to find out they don’t need it and it needs to be removed.
• #13: Requirements! Having requirements and acceptance helps all of us know; When has build stopped? When is a sprint over ? When are we happy with the function? It needs to be recorded, in writing and reviewed. It ideally is done during the define stage but can be revisited and debated through out a project. If we fail to communicate we fail to agree on the definition of done as a project team and instead assume our own definition. Here is an example and this is the core of every project!! But if you haven't written it before and everyone is on a time sensitive path to get things done – this is dropped or consultants end up writing it all themselves. Marking our own homework or making large assumptions about the business. This confirmation of done feeds into testing, feeds into training, feeds into your documentation. If you can ace this then you will find it much easier to move forward when you get to build and test!
• #14: Miscommunication not only means the wrong words said, but the tone, the choice of tool to communicate with. Annual leave, calendars, I regularly announce my countdown to my holidays it makes sure people are aware and creates a better project culture. If something is serious and urgent and will impact on the overall project, a private message to a team member is not sufficient. They may not understand the urgency because it doesn’t impact their work, they may not pass it on. Fear of being wrong in your communication can also hold a person back. A customer subject matter expert doesn’t think the requirement has been captured accurately. They can see that there is something missing but because they are working with an experienced consultant it is assumed that they will catch it. Its their job they probably already saw it and will deal with it later. The same can be said for a consultant seeing something missing in a process but assuming a customer would have said something. Diffusion of responsibility. Corporate bystander effect. You see something going wrong and you assume someone else is responsible, will deal with it or already has. Only to find out everyone thought the same. The more people on a project the less people are inclined to take responsibility. We are humans and sadly we do read minds! So create Ohana and be open to having people point out something that may be missing for the good of the project!
• #15: How do we stop this?! Regular meetings, regular standups, regular updates to those who will be impacted. Clear defined path that is revisited regularly to ensure everyone is communicating. Commit to writing the requirements and the acceptance criteria at the start of your projects. Together make sure all project members have the definitions and the understanding. Take the time to read through them together at the start. Encourage people to speak up ! Make a buddy system for clients and consultants. Use chat groups. Create an environment where people feel they can say something, As a project team member – if you feel something isnt right, even if its just a feeling in your soul. Know that saying something wont have a negative consequence. It may actually save the project. it takes time to build but if everyone knows the intention – which is to win at a project. You get buy in.
• #16: Customers, consultants – I don’t need to plug the wonders of Trailhead – free platform for learning but if you are going to question why a function takes so long to build or why it needs to be customised this is the place to get a good understanding of the platform. Consultants you can create trail mixes for your customers so they don’t get lost in all the amazing modules. Consultants have certifications! These a great and add to your knowledge base but don’t disregard project experience! Currently I am in a service cloud implementation and my omni channel experience from 2 years ago is paying off because I know exactly how to build out what I need. It consumed my work life last project. Its like riding a bike for this one. Project management tools, design tools, communication tools. I don’t have skype anymore but some people do. My laptop is a mac I'm not sure how to use anything else now. Are we saving everything to a share folder? IF yes- put things in the share folder. What licenses have we got ? How many sandboxes are we going to use. Salesforce dx, git hub, and continuous integration have been my learning curve recently. I didn't’t have a password, when I got that the RAM on my laptop failed. The CI process steps are a little different to our usual practice. And due to lack of time to set up. I took up a day of not only my time but my technical teams time to work out that I NEED A NEW LAPTOP! Tool fail. THANK goodness salesforce is on the cloud. I didn’t lose my build. But I did lose a lot of time I have had to make up for. Check out my linked in for my article that is my personal CI journey!
• #17: ROPE is not the best at holding a structure together! And gluing it is not the best technique. So why do we select tools that are not appropriate for our projects. How do we stop this? It starts in the planning stage and while everyone is researching the hows and the whys these tools should be selected. A Project management tool to hold the requirements and the estimates to track the build. A calendar tool to track peoples leave and availability. A communications tool email and messenger to tie people together Correct licenses and access should be granted well before build begins. Deployment method and tools should be agreed and installed the same time as licenses. Put time for it in your project plan and in your week to upskill those who come on to the project and don’t know the tools Set this all up before build begins.
• #18: You may laugh but these are sayings I have heard time and time again and they are not said for ignorance. It is because of TIME ! All the build, all the questions, all the communication everything sounds like its coming along GREAT! So why do we have to test it and why cant the consultant do it ? They know this stuff better than I do – how am I supposed to tell if its working. Why cant this just go into live? ALL pains we have all thought. Not just the customer. As a consultant I too have to check my teams work. And some days I wish I didn’t because I don’t have the time. BUT I do it because if I can find a mistake before someone else down the line does then I wont have to dedicate time to fixing it later.
• #19: User stories + Acceptance criteria come in to play and where the real team work kicks in. If you’re building a structure you check that it can hold your weight and it does what you need it to do. Will they be able to use it ? Do they know how to use it? Have they tried it - if I build a small tunnel that only I can fit in - I don’t know until it’s tested. Someone has to check that I have fulfilled my obligations to this project. If we simplify It. . I can build it and test it. I can tell the next person. They take my word for it and tell the next person it works, they tell the next it works. No one has checked if it works. And no one will find out until the end that the requirement was wrong, my solution wasn’t the one that was expected or that I only tested as a system admin and it doesn't’t work for any other profile. Would you tell you bosses bosses boss that everything works perfectly without testing it yourself ? In essence that’s what happens when people try and skip it Testing sounds uncomfortable and scary to those who have not tested before but really its your chance to get in and get a VIP tour of the new solution hitting your company. Testing is the chance to become a champion in the office, you are the first in the know! When this thing comes out people will look up to you for knowing your way around.
• #20: How do we stop this Clarify user stories, acceptance criteria at the beginnning. During each sprint confirm the stories and acceptance are still valid. Have those that are going to test it attend the show and tells or give them regular updates on how the build is progressing Involve them in the scenarios that they will need to test. These come from the acceptance criteria. They don’t have to be technical they can be a story. Create a plan. Either rolling testing or blocks of testing Allow your testers the time to test If the testing is not complete – do not skip to the next part of the project. It will hurt the project adoption. It may end up affecting the business Consultants take the time to show has been built. Record it and share it
• #21: So quickly to reduce the cost of a project this one of the first things to be taken off the table or something that is left to the very end when the time is tight. How do future users use it – how do we remember what we built for phase 1 to determine what should be built for phase 2 Extensive Health checks and discoveries will be required for the next stages Roll on of new project members - long periods of onboarding. Dependency on those who gathered the requirements What does QA follow – How do users understand their solution. During the project things have been writing down by individuals- the collation of it and the organisation of it is what will make the hand over of the solution smooth We say “out of the box” but there are so many ways to configure out of the box. Without directions on where to look how do you know what you are changing / breaking and how do you check fo best practice as a customer without any record of what has been done?
• #22: It is the core to adoption for future users! The core for the continuation of the use of your solution. Here are some ways to create documentation - record when you show and tell (demonstrate a function) the requirement is to have a secret entrance with a sequence of tasks to gain entry. No one wrote it down! New club member joins … they cant get in. Video, Document Infographics Share Drive Salesforce files Training slides Training activities Give time to the project for both sides to create content. Assign a role to their maintenance and upkeep
• #23: The cycle of maintaining all 5 things while on a project is constant. Not only is it good for the end result it is good for the journey People can be added to the project at later points, and others may have to leave. People may not want to leave and try stay! Staying on top of them will enable new users to contribute quicker and without as many errors. The wider business looking in wont see a delay or lag in timelines.
• #24: Its not all roses !! But if we have balanced out the scope triangle and we have kept on top of the 5 points that I think are key to a projects success. Then we replace with bitter taste with a sense of achievement. My best projects are the ones where we nailed the requirements and we gave some more on top because we had spare time. They are the ones that I think of and wonder how they are or the ones that I get excited to catch up with knowing they are going into their next phase. People that I keep in touch with on linked in are people I want to work with again. No one is perfect but when these 5 ways of losing a project get the attention they need it creates an environment of respect, growth and achievement. Coming together, working together creating the Ohana in your project. Having shared this, If I get the chance to work with any attendees in the future, I know we will achieve at least THESE 5 things.