In many of my past entries I've discussed various issues that can cause a project to go off the rails. This could be anything from a minor irritation within the overall lifecycle, or it could be more significant causing a reevaluation of the overall project. Obviously, I'd much rather deal with the former vs the latter, but as with anything in real life, we don't always get to choose the trials that we face. And, sometimes we learn the most as we fight through the fire.
One of the things that I'd like to tackle in this particular discussion is the need for true open and honest communications between all members of the team. Many times, an issue that surfaces within the overall project is the culmination of the effect of someone not getting out of their seat and talking with a team member. Ok, getting out of your seat may not be the right terminology in today's connected and distributed world. Team members have many options to connect with other team members - email, instant messaging, video conferencing, texting and - wait for it - good old fashioned face to face discussions.
Let's be honest with each other - how many times have we all been irritated and wanted to pull our hair out because the response we get from someone when it hit the fan was, "Well, that's what I was told to do.", or "That's what the design said to do." In most instances I then ask the team member, "But you knew that wouldn't work, right?" And in most instances I'll hear them admit that they knew the design was wrong or that the item in question had been overlooked or that they didn't feel that they could discuss it with someone else on the team.
To be clear, this is an example and the point of this post is not to lay blame for all issues at the feet of the requirements or design teams. In many instances, the people doing the requirements and/or design work don't necessarily understand all of the fine details of how the system is plugged together. Understanding the fine technical underpinnings of the system is the responsibility of the technical teams.
If someone, anyone, on the project team identifies that something is missing, incomplete or just not right, it is their responsibility to get it corrected. By whatever means are necessary. It is not proper to sit on the issue and knowingly let your teammates head down a false path, or to let the project stall. If you're truly on the team, you're invested in making the team, the project and the company successful in creating solutions that can be used by your customers. The key phrase, "you're invested"! If you're invested in the idea, then that means you're taking it personally to make sure that it's right and that the end result exceeds expectations.
How difficult is it to poke your head up from what it is your doing to have a conversation? Not every issue requires a meeting with 10 people in the room looking for various options and contingencies. Take a stab at solving the issue on your own with a few key people. Review your thoughts with key individuals on your team and then make it happen - get it corrected and resolve the issue before it has time to fester and become a potential roadblock to the project. If you can't get to the bottom of it and find a reasonable solution, then work with the Project Manager to get a larger team of individuals to together to work through the issue. Oh, and by the way, make sure you're keeping the Project Manager in the loop on what you've found - that doesn't mean they need to take control of the situation, it just means you're keeping them informed. In fact you can tell them upfront: I don't need you to get involved. I'm working through some options right now with a couple of people, if we can't find a solution by the end of the day, then I'll need you to step in and assist with coordinating a larger part of the team to help find a solution.
As I've said in past postings, people are messy. We all make mistakes from time to time. Maybe when putting the design document together I forget that a certain data element needs to be replicated to another application in the enterprise. By forgetting to include this in the overall design, I have inadvertently introduced a situation that may impact the companies ability to bill for certain services or maybe the information won't show properly to the customer service representative answering customer calls. In either case, the mistake was small, but the impact to the customer is real and measurable.
If down the line, one of the software engineers notices that I overlooked documenting how the data element needs to be replicated between systems - it isn't the end of the world. A quick call to confirm that "not replicating" the data wasn't an intentional decision and in fact was a mistake - allows the project to proceed. Documents can quickly be updated and the change communicated to the rest of the team. However, if the software engineer sees the mistake, doesn't say a word and we get all the way in to production without replicating the data, we have negatively impacted our customer by potentially billing improperly for services or by delaying assistance when they call in for help.
Look, one of the reasons we are all in the jobs that we are in, is to solve problems. Sometimes that means sitting at your desk and doing what's in the job description. However, in today's world, the job description is just the start of what you really do in your job. You've also been hired to be part of a team! It means removing the small roadblocks before they become big roadblocks. It means uncovering and resolving those inconsistencies before they can be seen by the customer. It means finding ways to work with others to provide the unexpected. It means noticing that your teammate is stuck and helping find a way around the obstacle. It means thinking through something that you believe is wrong - validating the assumption, and then working with the team to provide a solution before the issue has a chance to delay the project, increase costs or call in to question the need to finish the project.
Today, we are hyper-connected. Take advantage of the tools that you have to break down barriers and talk with those around you to solve problems. I don't want you to think that your job is to just satisfy the "requirements" or "design documents". I want you to challenge those things that you think are wrong or that negatively impact the customer and work with others on the team to identify solutions that allow the project to move forward and meet or beat the timeline, reduce the overall effort and provide a superior solution.
Tags: SDLC, Software Development Lifecycle, Project Lifecycle, Project, Manager, Development, Paradigm, Security, Secure Development Lifecycle, Communication
For more information on David L. Collison: LinkedIn Profile
As I've said in past postings, people are messy. We all make mistakes from time to time. Maybe when putting the design document together I forget that a certain data element needs to be replicated to another application in the enterprise. By forgetting to include this in the overall design, I have inadvertently introduced a situation that may impact the companies ability to bill for certain services or maybe the information won't show properly to the customer service representative answering customer calls. In either case, the mistake was small, but the impact to the customer is real and measurable.
If down the line, one of the software engineers notices that I overlooked documenting how the data element needs to be replicated between systems - it isn't the end of the world. A quick call to confirm that "not replicating" the data wasn't an intentional decision and in fact was a mistake - allows the project to proceed. Documents can quickly be updated and the change communicated to the rest of the team. However, if the software engineer sees the mistake, doesn't say a word and we get all the way in to production without replicating the data, we have negatively impacted our customer by potentially billing improperly for services or by delaying assistance when they call in for help.
Look, one of the reasons we are all in the jobs that we are in, is to solve problems. Sometimes that means sitting at your desk and doing what's in the job description. However, in today's world, the job description is just the start of what you really do in your job. You've also been hired to be part of a team! It means removing the small roadblocks before they become big roadblocks. It means uncovering and resolving those inconsistencies before they can be seen by the customer. It means finding ways to work with others to provide the unexpected. It means noticing that your teammate is stuck and helping find a way around the obstacle. It means thinking through something that you believe is wrong - validating the assumption, and then working with the team to provide a solution before the issue has a chance to delay the project, increase costs or call in to question the need to finish the project.
Today, we are hyper-connected. Take advantage of the tools that you have to break down barriers and talk with those around you to solve problems. I don't want you to think that your job is to just satisfy the "requirements" or "design documents". I want you to challenge those things that you think are wrong or that negatively impact the customer and work with others on the team to identify solutions that allow the project to move forward and meet or beat the timeline, reduce the overall effort and provide a superior solution.
Tags: SDLC, Software Development Lifecycle, Project Lifecycle, Project, Manager, Development, Paradigm, Security, Secure Development Lifecycle, Communication
For more information on David L. Collison: LinkedIn Profile
No comments:
Post a Comment