Project Management Is Such A Lonely Phrase

Project Management, is like the word honesty from Billy Joel’s hit song titled “Honesty”.  Project Management is such a lonely phrase!

Let’s get down to the brass tacks – Project Management at its most basic function is responsible for managing the three sides of the triangle: time, budget, and scope.  Project Management requires the Project Manager to utilize their knowledge, skills, tools and technique to oversee a team of individuals and deliver against the Project Requirements, within the allocate time and budget with the approved resources.

If a Project Manager is to be successful, they must view themselves as the only source of truth.  At times, they must set aside the need or want to be liked by the team so that they can provide a true assessment of ongoing activity to the Project Sponsor.

Let’s face it, at times, the teams like to sweep issues and risks under the table so that they can present a warm and fuzzy view of the project to the Project Sponsor and the Project Management Office.  The Project Manager sometimes enables this behavior because they want to see their status in a ‘happy state’.  This also reduces tension within the team, because the Project Manager is not confronting the issue.

Well, that’s just plain wrong!  I’m sorry, but as a Project Manager, you role is to highlight to the Project Management Office and the Project Sponsor when tasks are not being completed on time and the risk to the overall project.

Now, I get it!  Not every task will be completed on time, but there are milestones that activity should be tracking to that allows the Project Manager and others to get a sense of whether a project is on track or not.  A given task may be late, but not risk the overall milestone.  However, if the milestone is at risk, either from a time or budget perspective, than the issue/risk needs to be highlighted, mitigation plans need to be identified, and communication needs to occur.  It is possible that thru the mitigation plans identified by the team that the Project Sponsor will allow the team to address the issue or risk.  However, if it is a key milestone and the Project Sponsor is not comfortable with the mitigation plans, they then have the opportunity to engage and assist the team in getting the issue corrected.

As a Project Manager, you are the source of ‘Truth’ for the project.

Resources like to always look at their own package of work and paint a rosy picture.  They will find reasons – not their own – as to why something is late, or why it’s costing more than was budgeted.  As a team, they will work together to gloss over the truth and allow the Project Manager to report a rosy picture from week to week.  I’ve heard things like:

•      Yes, we are running over the timeline to get requirements complete, but we’ll make up for it somewhere down the line.

•      Yes, the designs aren’t ready to go, but everyone knows the estimates put together for the actual construction are way high, so we’re good.

•      I know development is taking longer, but we don’t actually need all the testing time that is shown in the plan.

•      The contract firm that is doing that piece is late, but that’s ok, we can still get all of our pieces in on time.

None of the above statements (or any other excuse) is acceptable.  As the Project Manager, your job is not to go along with the team. Your job is to identify the issue, create a mitigation plan and communicate it up the chain to the Project Management Office and the Project Sponsor. Once the issue has been highlighted, maybe additional resources can be applied to bring the timeline back in and meet the next milestone. Maybe the Project Sponsor accepts the recommendation from the team that the milestone can be missed, but the overall plan can still be delivered within the identified timeframe. But at least, the Project Sponsor and Project Management Office are aware of the issue and can work with the team, vs being surprised at the very end that a project is being delivered late or over budget.

As ‘truth brokers’ you are keeping the team members honest with each other and are keeping the lines of communication open up to the Project Management Office and the Project Sponsor.  This truth is critical as it allows the Project Sponsor to accept the truth without questioning the motivations and ultimately forces clearer communication between team members. 

Telling the truth should not be viewed as a negative, but should be viewed as the core responsibility of the Project Manager.

If you'd like more information on my background: LinkedIn Profile

Dysfunction within the Team - Breaking down the barriers!

Sometimes I'm left surprised when an issue hits my desk and I begin to work backwards to find out what happened.  In too many instances, I can trace it back to follow-through.  Someone in the organization knew something, or was assigned to do something and for some reason forgot.  What's even more irritating is when I'm the guilty party!

Recently, I was rightfully called out by one of my peers for not communicating a decision impacting a critical project out through the organization.  She had every right to call me out on the lack of communication.  It was my error and I could do nothing but agree with her and acknowledge the failure.  I like to pride myself on the fact that have strong communication skills and working relationships with my peers, and so I take this one personally.  There are many excuses that I could use - I'm too busy as we move several key projects into production ahead of our year end production freeze; the Project Manager should have communicated that out to the team.  Ultimately, I made the decision and I had the responsibility to communicate the decision across the organization - especially when that decision was going to put pressure on other teams across the organization.

This is not unique to myself.  As I began to explore at the beginning of this post, too often I look at the root cause of an issue and it all goes back to someone knew and didn't think to share that knowledge.

I recognize that some of this is human nature.  In the heat of the moment, decisions will be made that we believe will move the process forward and get the entire organization closer to the end goal.  While that may be the case - follow-up is critical.  Let's face it, we've all sat on the receiving end of some decision that made our lives miserable.  We've had to deal with the fallout when that information comes at the last minute.  I will be the first one to step up and call someone out when they do that to myself or one of my teams - it's only fair that I take the feedback when I'm the one causing the problem.

To allow this type of honest feedback - you need to be willing to trust the teams you work with on a daily basis:

1. Your direct reports
2. Your peers within your supervisors team
3. Your peers across the organization with whom you deal with on a daily basis

One of the best books that I've read on this topic was written by Patrick Lencioni, "The Five Dysfunctions of a Team".

This book leads you through a scenario of how a group of individuals that didn't work or trust each other was transformed into a highly functional team.

I was first introduced to this book, by my current boss - our CIO.  It was the first thing that he wanted me to read after I was hired.  In fact, he sent it to me before I even officially started.  It is now one of my favorite books.  I in turn have required all of my direct reports to read the book.  I encourage my team to be honest with each other and to hold each other accountable in their daily interactions.

We have been hired for a purpose.  We are here to make a difference, to move the ball forward.  That means holding ourselves and others accountable for the deliverables that people throughout the organization rely on so that they can do their job.  We must open ourselves up to others, understand the story that is driving their actions and be prepared to receive open and honest feedback when we fail to live up to our commitments.

Don't get me wrong - this isn't a directive for you to walk around the building pointing fingers at people and telling them they're not doing the job - chances are if you did you'd have a line of people at your desk telling you that you didn't do your job.  What you should do is be willing to engage in a positive open communication.  Explain what you are seeing - you may not have a full understanding of the situation and be prepared to change the direction of the conversation based on what you hear.  If the person truly is responsible for failing to deliver, than it's up to you to find a positive way to work with the person and manage the situation.  Help them help you!

If you'd like more information on my background: LinkedIn Profile

Communication: You might be the Problem!

How many times have you entered into a conversation where you knew you had the answer to an issue, you just needed to sell the others. Much to your surprise, when you presented your idea you struggled to get the expected buy-in. In your mind, it was obvious what needed to be done, but you couldn't get others on board.

Well, it just might be because you didn't know how to communicate your ideas in a way that others could understand, or in a way that they felt safe buying into your recommendation.
Let's take a look at the 4 different Social Styles as documented by Larry Wilson:

• The Driver - these are the folks that just want to get it done! Given the opportunity, they will take charge.
• The Analytical - these are the folks that want to know the facts! Before diving into an assignment, they want to know all the details.
• The Amiable - they want to be your friend. Relationships drive their world. They are very loyal and want to know who they can work with and why it needs to be done.
• The Expressive - these folks have a lot of energy and have a "let's do it" attitude. They are spontaneous and will struggle with commitment and follow-through.

If you want to be successful in the interactions you are having with others, it is imperative that you understand what makes that person tick. Then guess what - it's you that needs to change your approach! Yep, you need to take the time to figure out who your interacting with and be able to modify your communication style to win them over.

• The Driver wants you to cut to the bottom line. Expect them to be business like and outspoken. They can sometimes be poor listeners and want to control the conversation. They will freely interrupt the conversation to get answers to questions and will summarize to move the conversation forward. To be successful: focus on the problem at hand, be brief, speak in terms of results, give them options to choose from and allow them to feel in control.
• The Analytical wants you to talk facts. Expect them to set high standards for themselves and others. They will have limited expressions and eye contact during the conversation. They will focus on the detail and will want to ensure the accuracy of any assertions. They expect you to be logical and well organized and will expect you to do what you say you will do when you say you are going to do it. You need to allow them time to think through things and don't force a decision.
• The Amiable wants you to avoid conflict. They will want to focus on the traditions and will want to be flexible in how the approach the issue. They will want to keep things easy and informal. They will want to allow time for the team to feel good.
• The Expressive want you to seek their input. They will focus on the future and want to illustrate points with stories. They will want to focus on the big picture and leave details to others. They will want you to compliment and recognize their contributions.

The trick is learning how to quickly recognize the social styles of the individuals you are working with and then being able to change the presentation of your idea to make it more compatible to how the person will hear the proposal. This isn't easy, and it take quite a bit of practice to master. What can really be tricky is when you are interacting with a group of many social styles and then understanding how you have to shift the presentation between the different social styles to win over the others in the room.

If you'd like more information on my background: LinkedIn Profile

Project Managers: Tactical ways to Push Testing

So, in my previous post, I talked about some of the high level things that you, as the Project Manager, need to be thinking about, as it relates to testing, when managing your projects.  In this post, I'm going to step down in to the tactical.  Specific things that you can begin to push within your projects and my recommendations for who should shoulder the responsibility.  These recommendations are based off of things that I've seen work in my current environment as well as things that I've seen work in various other organizations.

Now, before we dive in, a word of caution.  You need to evaluate what I'm saying and throw it up against the reality of the environment within which you work.  Some of what I say will work, some of what I say would probably spin heads within your organization.  Take what works for you and throw out the rest.  We're currently reevaluating some of the test strategies that are used within my teams and six months from now, I may have a different take on the subject.  My biggest concern is ensuring that we put enough thought in to the process to allow less experienced team members to be successful when working with unfamiliar subsystems or product features.

And, with that said, it's time to dig into the details and talk about things that I've seen work - note for those readers willing, I'd love to get feedback from others on what they are seeing work/not work in their environments.

First up, what are your end users (or the team members representing the end users) doing to drive the quality initiative?  These are the folks that are creating the user stories or requirements for the products that you're building.  Are they being held accountable at the start of the process to define what success means?  Are they telling you up front what they will do when performing user acceptance testing?  If not, it's time to sit down and have a conversation.  Why do they feel comfortable telling you what to build if they can't tell you how they will know it is right?  Specifically, what are the conditions and scenarios that they will use to validate that the functionality delivered is acting properly and producing the correct results?

1. What set of information needs to exist within the system to allow them to create the scenarios that they will use to test the requested functionality?  What specific elements of data will be used in the testing - both from a positive and negative test perspective?
2. What business logic is being used to assess whether the outcome is valid?  What will change within current processes?
3. Ultimately, what does success mean to them?  How will they know that what you've delivered works or doesn't work?

Now, ask yourself, if these do not exist prior to the design and development of the solution, how will the team know that the proposed solution will actually solve the problem?  This function must be driven by the end users (or those team members representing the end users).  They can collaborate with others on the team, including business analysts, technical team members and dedicated testers.  But, ownership of the acceptance test plan must fall on the shoulders of the end users.

One of the things that I like to do once the users have defined their needs and the design phase is underway, is to have the technical subject matter experts (SME's) begin to identify high level integration test objectives.  This is built at the same time that the technical design is being worked and is a very brief document outlining the gotchas that the development teams need to be aware of when developing and exercising the new systems/features.  This is intentionally kept very high level - usually just descriptions of each item that will need to be fleshed out in later stages.

1. Identify touch points between various sub-systems that will need to be tested.
2. Identify data replication strategies that will be used and that will need to be tested.
3. Identify data transformation strategies that will be used and that will need to be tested.
4. Identify services that will be relied on that will need to be tested.

This acts as a roadmap for the entire technical team.  It should be a roadmap used to identify data validation and functional validation.  It can be used by those that may be unfamiliar with specific subsystems to gain a further understanding of the interrelationships between the various subsystems and external/internal services.  The IT SME's own this high level integration test plan and pass it along to others in the process.

As we dive down in to the detail design - several things begin to happen.  First, the development team begins to flesh out the high level integration test strategy and it becomes the Integration Test Plan.  This document details the specific actions that will be used to test the touch points previously identified and should include the data and functional validation - data should be traceable throughout the system with the end points being validated.  This includes identifying the specific data elements that will be used to perform the tests as well as the expected positive/negative results.  While driven by individual development team members, the plan will be reviewed and validated by the Technical Leads.

Additionally, the individual development team members begin to identify their individual Unit Test strategies.  Each functional unit of code being created or modified needs to be tested to ensure that it is performing to spec prior to moving in to integration testing.  I believe in the paradigm that the tests should actually be created prior to the code being written, but I've seen development teams be successful using several different paradigms - so I won't harp on it.  The individual developers own this and are responsible for ensuring that they develop clean code.

Once the developers have been able to execute their individual Unit Tests, then they work together and move in to pre-Integration Test planning.  This time is spent ensuring that the necessary data has been identified and created/setup, that the configuration changes needed to the system and supporting sub-systems have been applied, that the network configuration changes needed to open ports to talk to internal/external services have been applied, and that all of this has been documented for production.  This particular block of activity is owned by the Development Team and the Technical Leads.  Infrastructure Teams may support the activity, but the Development Team and Technical Leads should ensure the configuration is complete and documented for the Implementation Plan.

Now we step in to Integration Testing - executing the plan that was documented earlier.  It is inevitable that something will have been missed - but that is what this stage is for, to find the bumps before you move your changes into the quality assurance (QA) and production environment.  Here you will find the missing data elements or calls to services/api's that work differently than documented.  You will uncover the fact that replication strategy for data you rely on wasn't documented properly and the underlying data you were expecting to see doesn't exist.  All sorts of unknowns will surface and you'll spend time playing whack-a-mole to clean it all up to a point where you believe it is functional.  The Development Team and the Tech Leads own this piece of the puzzle and work to ensure that all of the individual pieces come together and work as a whole. 

Now, let's take a few minutes to talk about Regression Testing.  I'm actually in the midst of transitioning our teams form the old style of moving code in to QA and then running a full regression test of the code along with new function/feature testing to a model where the code is built nightly and then the suite of regression tests is run when the build has finished.  This has been a tectonic shift for the teams in that the developers are getting daily feedback on code that has been checked in to the repository and we actually are building up a set of statistics that show us the overall state of the code.  I can now walk in on a daily basis and see the various package builds, number of tests being executed and the success/failure rate - along with a whole suite of statistics on coverage and severity of the failures.  Benefit number one - immediate feedback to the development team while the code is still fresh in their minds.  If we need to change something due to a failing test, the developer doesn't need to spend time remembering what changes were made.  Benefit number two - reduction of effort by our QA Team Members to get code through the testing process - their focus is on new feature/function testing, not regression testing.  Benefit number three - the developers have more buy-in on the testing process and begin to have a better understanding of the underlying data.  The Development Team is responsible for the Regression Testing and must review the results with QA to validate that the code is ready to move in to QA Testing.

QA Testing is focused on the new features/functionality to ensure that they are operating within defined constraints.  Here is where I want to hit the system hard with positive and negative testing associated with the new features/functionality being introduced within the overall system.  What happens where certain pieces of data are missing from messages exchanged between subsystems?  What happens when a user forgets to input data?  What happens when a web service that we are relying on isn't available?  What happens when the system thinks everything processed fine?  I will also want to take a look at load testing on some system to ensure that we are staying within expected SLA's.  This testing is the responsibility of the QA Team with input from the Development Team, Tech Leads and support from the Infrastructure Teams.

As  part of the work that is being done during QA Testing - we should also work with those team members representing the end users to execute the User Acceptance Tests (UATs).  This should tie all the way back to the beginning stages of the project where the business teams defined the success criteria of the effort and began building the definition of their UATs.  During the entire project, these high level UATs should have been fleshed out and reviewed to ensure that they align with the final requirements of the project.  QA and the User Teams should jointly execute and review the results of the associated UATs and prepare to sign off and give final authorization to move the code in to production.

As a Project Manager, you need to assign tasks to cover these activities within your overall project plan.  More importantly, you need to be following up with the responsible parties at various stages of the lifecycle to ensure that they are not being ignored.  Your organization may hold different team members responsible for the specific activities outlined.  They may also skip some of the items outlined above.  However, you need to ensure you are covering enough of the pieces to confirm that the system being built will satisfy the requirements originally identified at the beginning of the overall effort.

Well, we've reached the end of the discussion today.  I hope that you've found some of what I've discussed useful and that you're able to take pieces back in to your organization.  Feel free to share and let me know your thoughts on what has been presented and let me know what works in your organization.

Tags: SDLC, Software Development Lifecycle,  Project Lifecycle, Project, Manager, Development, Paradigm, Security, Secure Development Lifecycle, Communication, QA, Quality Assurance, Testing

For more information on David L. Collison: LinkedIn Profile

Project Managers, Bake Testing in to all of your Projects!

Well, this week I'm going to jump back in on the topic of quality - more importantly the need to build it in from the start.  This is a topic that many teams struggle with - how much testing is enough?  When do you call it good enough to move code in to production and celebrate success?

While I can't give you a definitive answer, it is important for you to look at each project and assess the risk of failure.  More importantly, you need to look at the various functional areas and ask yourself - what if there is an error, what will the impact be?  How will the application be used?  What is the audience?  What if this error is impacting one user?  What if this error is impacting multiple users?  Can downstream processes within the application - or dependent applications - continue to operate?

One of the questions that I've been asked by various developers - why are you making me do all this testing?  Isn't that the job of QA (Quality Assurance)?  Well, I hate to burst your bubble, but everyone is responsible for the quality of the end product.  Depending on the structure of the overall team involved in the project, the level of effort of the developers dials up or down.  If the organization has a strong QA Team, the developers may only be responsible for unit testing and some level of integration testing.  In other organizations, development may be responsible for everything up to and including user acceptance testing.  In web facing projects, business representatives may be integrated in to the Agile team and test directly with the developers - with the developers making changes on the spot.

I'm not going to try and convince you to pick one methodology or paradigm over another.  Each organization is unique and your organization has built the test structure that is being used for some set of reasons.  What I am going to do is explain some of the things that need to be done along the way - I can tell you who within the project I think is responsible, but this probably won't match up with your organization.  (I'll let you in on a little secret - it probably won't even match up with the way that my teams handle testing.  We're reworking how and who performs testing, so some of this is still up in the air as I write this blog entry.)

Whew, now that we've laid the ground work, let's dig in to the details and see if we can make some progress. Regardless of what methodology that you follow to develop software - the quality equation must be dealt with at the beginning of the project and must touch through all of the parts of your lifecycle to ensure that you're providing the highest quality software in to the production environment.  This is just as true in an Agile environment as it is within a waterfall environment.

So, let's touch base on some of the key things that need to be addressed by the overall test plan associated with your development effort:

1. Acceptance Criteria - when the team thinks it is done, what will be used to judge whether the software can move in to the production environment?
2. Integration Test Strategy - what are the application touch points that need to be addressed?  This includes system to system touch points - messaging, it includes intra-application - application sub-systems - that need to be tested, if your replicating data - it should include testing the replication mechanism, and it should also include testing of the security mechanisms used within the application.
3. Regression Test Strategy - is it necessary to perform a full regression test against the application, or is it valid to consider a limited regression test based on the functionality being touched by the development team?
4. Test Data - what data can be used to ensure that you can execute all of the tests needed to validate the functionality of the system?  This should include both positive and negative testing of the application.
5. Recovery Test Strategy - depending on the system you are building, you may have include functionality to allow the system to recover from various types of failure points - if so, you need to ensure that you test the recovery functionality?
6. Security Test Strategy - depending on your application, you may or may not need to include elements to secure the data being captured and/or manipulated by the system.  If this is the case, you need to ensure that you are testing the security elements to ensure that you are not allowing access to sensitive and secure data to individuals that do not have the proper authority.

On top of all that, each individual developer should be responsible for developing and executing unit tests against the code that they are developing.

All in all, there is a quite a bit of activity that surrounds the overall test strategy associated with the development process.  You may not formally address each of the individual items identified above, but in some way, these will get addressed throughout your project.  Either by accident or by design, someone should be answering the above questions before you put your code in to production.

As the Project Manager, it is to your benefit to ensure that these questions are being asked early.  This allows for the entire team to proactively address the test strategy and test requirements.  What good is it for development to be finalized if the development team doesn't understand how they will perform integration testing, or if the team doesn't understand how they will validate the acceptance criteria?

Next time, I'll dig in to some of the tactics that I've used - both within the current Teams that I work with and within previous organizations where I've worked.

In the meantime, feel free to chip in to the conversation and talk to me about the strategies that you use within your teams to manage your test strategies.  What are the components you feel are important and who within your teams has responsibility?  I'm not hear to judge what anyone does, but by sharing, we all might learn something new.

Tags: SDLC, Software Development Lifecycle,  Project Lifecycle, Project, Manager, Development, Security, Secure Development Lifecycle, Communication, Testing, QA

For more information on David L. Collison: LinkedIn Profile

All it takes is a little communication

Back in action again with another posting.  My activity on this blog slowed down over the summer months as I focused on work and relaxing - probably a little more on the relaxing side.  Now it's time to  get back in the groove and start sharing again.  For those of you that have been reading this blog for a while, I hope you enjoy the new contributions!  And for those of you seeing this for the first time welcome - I'm attempting to share my thoughts and opinions on the software development process and the roles that people play.  My hope is that everyone reading through these articles can take away something that helps them, and that through the messages that I receive, that I learn something along the way.

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