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

Project Management for Developers

Developers, Software Engineers, Code Guru's, Programmers ... this one is all about you!  Yep, I've published several posts, but haven't directed any at the folks slinging the code on a regular basis until today!  When I look back on it, that's pretty amazing, considering software development is where I started and that it is an integral part of the Software Development Lifecycle.  So, today we're going to mix things up and put the spotlight on this merry band of coders!

I've had the pleasure of meeting lots of developers from around the world in many different organizations that I've worked for - either as an employee or as a consultant.  I'm still surprised when I meet individuals that think of this profession as some sort of magic.  They are perplexed that men and women sit down and create all of this stuff that we now use as a part of our regular lives - apps on our smartphones, apps on our tablets, the programs we use on our laptops and desktops to the applications that we run on our thermostats in our homes.  You seemingly can't go anywhere without running in to things that are run by software.

My first professional programming jobs used things like dBase III, Clipper and Basic - storing information in dBase III file formats.  And yes, I've just dated myself!  Anyhow, I then graduated on to Visual Basic, C, C++, C#, Java, JavaScript, Ruby, Ruby on Rails, a very brief stint with Assembler.  Data was stored in Oracle, DB2, MySQL and SQL Server  You get the idea, I've worked in a lot of languages and haven't even listed all the scripting tools I've used over the years.  I've used these languages in all sorts of shops - sometimes it was on projects where I worked alone (oh, how I long for those days).  Sometimes it was in large organizations, with sophisticated development processes, where teams were located across multiple locations and continents.  Sometimes I got to sit next to the people who would end up using the code that I was writing.  Sometimes I never met the people - I worked from written documents and interacted with the project manager and quality assurance team.  Sometimes the code that I wrote was used by 1 or 2 individuals, sometimes it was used by people across the globe.  

I love writing code, and even though it's not my role anymore, I still write code at night so that I can continue to learn and keep my skills somewhat fresh.  I won't kid myself to think that I can get back down in to the trenches with some of the developers that do this all day long, day in and day out.  However, creating software is still something that I like to do - I can really get in to the zone and not realize that hours have gone by, before I come up for air.

Now, along the way, I caused my fair share of Project Managers to loose sleep, go grey prematurely, and I'm sure I did a number on their blood pressure.  In many ways, when I first started, I didn't understand my role in the whole project thing.  Wasn't I just supposed to sit at the keyboard and make it happen!  As sure as I'm sitting here writing this article, I'm positive that my old managers, and project managers that I worked with, would tell you that I wasn't too keen on following the rules.  To be very blunt, I was aggressive in the way that I approached my job.  I wanted to get things done - heck, talk to the people I work with today and they'll confirm that last statement.  I'm still aggressive - the difference is that over the years I've learned to temper my natural tendencies and understand that sometimes rules and process do add value to the overall flow of the Project Lifecycle.

Wow, that was a long winded intro to the topic!  And, if you haven't figured it out yet, I want to talk about the person generating the code and their role in the Project Lifecycle process.  

Take a look at the titles at the top of this posting - I generally don't care what you call yourself, you're developing software and you do have some level of responsibility to your team.  Even if you consider yourself a team of one, unless you are the only person that will ever use the software you are creating, the team is larger than yourself.  At a minimum, it is two people, yourself and the one other person on the face of the planet that is using your app.  Hopefully, the number of people using your app is a lot larger.  Many times, working in an organization, you will be one of a larger team - other programmers, the project manager, quality assurance, end users, designers, etc.

If you are developing code that others are going to use, you have a responsibility to the other people that are on the team.

1. Setting proper expectations as to when you will hit specific milestones.
2. Holding yourself accountable to complete the identified work between milestones.
3. Making sure that the quality of code being delivered to the test teams is adequate.
4. Keeping everyone that needs to know in the know on any issues that come up that are preventing you from making progress.
5. Helping to create mitigation plans when something goes off the tracks and is jeopardizing the milestones, the quality or the functionality of what is being delivered.
6. Ensuring that you keep focused on assigned project activity.

I will be the first to admit that creating software can be an art.  However, that doesn't absolve you of your responsibility to fit in with the team and support the goals of the project.

You see, here's the rub, when you miss the milestones for work your responsible for, the project and future projects all get impacted.  Somewhere, in the organization, plans have been made on specific things happening within a specific order.  Project A gets completed and moved in to production.  While Project A is moving it's way through the Project Lifecycle, typically Project B will get started so that when the developers are done with activity associated with Project A, new work is waiting for them.  If the work your responsible for is acting like a logjam, then Project A isn't going to get in to production and Project B's work is going to get delayed.  Now Sales and Marketing have a problem because they've promised customers that they'll be able to use the functionality by July 1st - whoops just kidding, can't get it to you now until September 30th.  Oh, and that new project you wanted started, we can't touch that yet - don't even bother to ask us about the delivery date.

This is real stuff, sometimes contracts have been written around the delivery of specific functionality, or entire marketing campaigns are laying in wait ready to go.  Sometimes those contracts have costs associated with them if the company you're working for can't deliver.  Sometimes the marketing plans are time sensitive and if you're late delivering the code to production, they have to spend additional dollars replacing the pieces of the campaign that no longer make sense.

And just so you don't think it's the non-technical teams that are affected, what about your buddies down the hall in the quality assurance area?  Any idea on what they are trying to juggle?  No, it's not just your project.  They have multiple projects coming through the pipeline hitting their test environment.  When they have to keep retesting your package because the quality is horrid and you keep crashing their system.  When they can't test because you can't deliver code in to their environment.  What do you think happens to finely tuned dance of projects winding their way through the various environments in to QA?  It all comes crashing down.  What you're not noticing is the scramble happening behind the scenes to put all the pieces back together.

Did you do a design?  Did you base your estimates off the design vs a hunch?  Those are bad problems to have.  Ok, there all bad, but those are really bad.  Did you misjudge one of the requirements and underestimate the time needed to develop something?  Did you encounter something in the test environment that caused your code to fail that wasn't within your control?  Those aren't good, but at least there's an explanation.  It's your responsibility to quickly inform the Project Manager of issues and whether you can get back on track, whether you need assistance in removing the road blocks, or if the problem really is of the type where there is going to be an unexpected delay.

I'm going to go back to a statement I've made before, we're human.  Sometimes we make mistakes.  Here's the million dollar question - did you make the mistake because you didn't want to follow basic rules when it comes to developing software.  Yeah, those rules, the ones your company calls the Software Development Lifecycle.  If you're not supporting the process, you're working against the team, your manager, the project manager, the department, the organization and ultimately your customer.

Tags: Project Management, SDLC, Project, Management, Conflict, Resolution, Project Manager, Software Development Lifecycle,  Project Lifecycle, Project, Manager, Development
 
For more information on David L. Collison: LinkedIn Profile

Project Managers - Yes, Sometimes You Are the Problem

In my last post, we discussed some of the issues that clutter the pipeline and prevent you, the Project Manager, from moving your project forward.  Missing deadlines, jeopardizing the budget or falling short of the resources you need to complete the project.  Well, today I'm going to ask you to take a long look in the mirror, because sometimes you, the Project Manager, are the one causing the problem!  Shocking, isn't it.

Now, let's not get all out of shape.  I'm not saying that you are intentionally torpedoing your own projects.  Rather that occasionally stuff happens and sometimes, just sometimes, you might be the one causing the issue.

We're all human!  And humans, by nature, are not perfect.  We err, sometimes it's the small things, sometimes it's the really big things.  What I want to explore in our discussion today is your responsibility as the Project Manager to look at things honestly and admit it when you're the one causing the wreck that is laying on the floor at your feet.

Throughout the overall project, the Project Manager has ample opportunities to stumble.  Let's take a look at some of the ways you might stumble as the Project Manager:

1. Mismanaging the relationship between the Project Manager and individual Team Members.
2. Mismanaging the relationship between the Project Manager and the Project Sponsor.
3. Mismanaging the relationship between the Project Manager and the Project Office.
4. Forgetting to send critical data to the Project Sponsor or the Project Office.
1. Expected cost over-runs.
2. Expected timeline adjustments.
3. Key resource changes.
4. Significant issues that could impact the project.
5. Forgetting to send critical data to outside vendors.
1. Changes/clarifications to specifications.
2. Changes to timelines.
6. Neglecting to send out meeting minutes with the associated decisions and action items.
7. Neglecting to follow through on an issue identified by one of your team members.
8. Neglecting to get feedback from the entire team when clarification/changes are identified

The list could go on, but I'm hoping that you notice that there is just as much opportunity for you to slip up and cause problems as the next person.

When something does happen, before you go out on the hunt to lay the blame on someone, make sure you've done your homework and you're absolutely sure that you aren't the one that caused the problem.  Nothing deflates and demotivates a team more than a Project Manager who doesn't acknowledge when they've caused a problem and deflects the blame on to someone else within the team.

Once you've figured out that you have caused a problem - you need to be the one to solve the issue.  Sit down, identify your mitigation plan.  Sometimes it's simple: you forgot to send out the meeting notes, send them out; you forgot to update a vendor on a date change, call them. 

Sometimes its bigger and could have damaging consequences - here is where true Project Managers show their metal.  Quickly identifying how they will mitigate the issue and then meeting with the Project Sponsor and key players to review what happened and what is being done to mitigate the issue and what you are personally doing to ensure that this type of an issue doesn't happen again.

I actually expect people to fail every once in a while.  The key is what have they learned from the experience and what are they doing to make sure it doesn't happen again.  If they can look me in the eye and tell me what happened and that they've admitted the mistake to those people impacted and are working to ensure it doesn't happen again, that's a good thing.

Tags: Project Management, SDLC, Project, Management, Conflict, Resolution, Project Manager, Software Development Lifecycle,  Project Lifecycle, Project, Manager

For more information on David L. Collison: LinkedIn Profile

Spear Chucking - Managing The Incoming Interruptions ...

Today, we're going to take a look at disruptions within the Project Lifecycle.  Specifically, those interruptions that can wreak havoc across the teams, timelines, costs and delivery schedule.  Sooner or later we need to deal with reality and reality is usually messy.  I have yet to see any type of a project where something doesn't pop up that needs to be addressed by the Project Manager or the Project Team.

First let's identify some of the familiar players that could end up disrupting your projects:

1. You Can't Do This Project Without Me: This individual lies in wait through the project and will find ways to be disruptive.  In most instances, these are very knowledgeable people who are afraid of sharing too much information.  They like to be viewed as the solution.  So they will identify something early on in the process and then hold it close until they feel it is the right time to "bring up their concern" and then be the one with the solution.  Sometimes they will work their "magic" through others, quietly whispering along the edge of the project until someone brings up the issue for them and then they can move in and be recognized for their "expertise".
2. I Know What Is Needed - Why Are You Wasting My Time: These folks view themselves as technical experts and don't feel like they need to attend meetings, read the requirements or test their code.  It is beneath them and they view it as a personal insult when someone actually asks them to explain what it is they are doing or how they plan to test the code that they are writing.
3. I Don't Really Support The Project: This person will pay lip service to what is going on.  But behind the scenes they are working furiously to deep six the project.  They view the project as disruptive or threatening and don't buy in to the value placed on the project by the Project Sponsor.  In meetings they will support you, but out on the floor they will attempt to undermine every decision made in conjunction with the project.
4. I'm Here To Make This Project Difficult: These folks find a reason not to do anything.  They will disrupt meetings with negative comments against individuals, other teams that interact with the Project Team, outside resources, specific project requirements, test planning and/or implementation planning.  It is their mission to disrupt at every stage, every decision point.
5. I Don't Report To You, You Really Can't Make Me Do Anything: These individuals like to play the game that they are only here temporarily and that you really don't have any control over them.  They will actively find ways not to work on the tasks that they have been assigned and will have glorious excuses of how they needed to work some other issue instead of the work that you have assigned them.

This is tough enough to deal with when the individual exhibiting any of the above traits is within the Project Team you are managing.  But what happens when they are outside the Project Team?  Maybe it is a resource manager who is supply team members to the project.  Maybe it is a Manager within the Finance Team who isn't on the project but doesn't believe in the promised results.  Maybe it is a Subject Matter Expert within the organization who feels that they need to be involved in the project.  Maybe it is a Senior Leader within the organization that doesn't support the Project Sponsor.

So, let's get down to brass tacks, what are the specific symptoms that you'll see - this is not meant to be an exhaustive list:

1. Withheld Requirements: Someone decides to withhold key information about specific requirements or withhold requirements in whole until designs are complete and development is well underway.  This one is particularly nasty in that you have to backup whole parts of the train and redo work.  This has the potential to disrupt project timelines, costs and needed resources.  Something is most likely going to have to give in the project.
2. Work Slowdown: This one is insidious.  You will slowly begin to notice that specific tasks are not getting enough work done.  Jeopardizing the completion dates of the identified task, as well as future tasks and milestones.  It has a tendency to sneak up on you - you won't find it all at once in a meeting or as you're updating information within your project plan.  It will slowly begin to show itself to you over a period of time.
3. Unresolved Issues Drag On and On: You will find that you can't close issues or identify working mitigation plans because you circle back and fight battles that have previously been discussed.  Your Project Meetings or Stand-Up meetings become dysfunctional and the Project Team begins to dread attending.  Individual work tasks aren't seeing progress because decisions aren't being made.
4. Team Cohesion Disappears: When the project initiated, it seemed like you had a great team.  People appeared to communicate well, supported each other and had bough in to the goal.  However, over time small conflicts turned in to larger conflicts and now the team doesn't put their oars in the water at the same time.  The project can't gain momentum.
5. Forced Death March: The Team has given up - milestones are continually missed, even after the team recommits to new dates.  No matter what you try, progress seems to be impossible to measure, but you keep slogging forward.

Now, I'll be the first to admit that sometimes requirements, or pieces of requirements, get missed.  It happens, we are all human and we can't always be perfect.  But this should be the exception, not the rule.  You shouldn't consistently see missed requirements coming from the same person or team within the organization.  If you do, it's your job to report this to your manager, the project office and the Project Sponsor.

So, here's the million dollar question - what do you do?  As Project Manager, this is what you're paid to do - solve problems.  Here is where you need to put on the gloves and get down in the trenches.  Communication is key and you need to pull out every option you have in your playbook.

If the issue identified is a missing requirement, maybe there is time, and enough available resource, to include it in the current phase of the project.  Maybe as Project Manager you will need to make the executive decision to withhold support of the identified requirement until a future phase of the project.  Maybe, with the support of the Project Sponsor, you will be able to delay the target date or increase resources to accommodate the identified change or new requirement.

Missing requirements, are actually probably the easiest issue to deal with from a project perspective.  The requirement is truly really needed or it can wait.  To some degree it is one of the few straight forward decisions you can make as a Project Manager.  Just make sure that you keep the powers that be informed and that you've documented why you are, or are not, going to make the necessary changes.

Other issues are more slippery.  They usually involve team members or other actors throughout the organization that interact with the Project Team.  Start with a 1-on-1 conversations with the offending party or parties.  Find out what is driving their dissatisfaction.  You might get lucky and actually be able to make an adjustment that allows you to sell the individual on the goals of the project and reengage them.  However, if after your 1-on-1 discussion, you don't see immediate improvement, you need to be ready to escalate to the resource manager, your boss, the Project Office or the Project Sponsor.

You will use every bit of charm you've developed over the years in these 1-on-1 sessions.  When held with members of the Project Team, they are usually fairly straight forward as you have some appearance of authority in the overall chain of command as it relates to the project.  However, this becomes more difficult as you identify individuals outside of the Project Team.  If these are individuals that are considered peers, it's your responsibility as the Project Manager to initiate the conversation to see if you can solve the problem.  

It the individuals causing the issues are higher up the food chain, then you need to document what you believe the problem to be and escalate through your boss, the Project Office or the Project Sponsor.  This is not easy to do, but it must be done.  If they are actively engaged in activity that could cause the project to fail, increase the overall costs of the project, jeopardize the identified timeline or impact the resources working the project, you have a responsibility to identify it, document it and get it to the people that can solve the issue. 

You can not allow these individuals to continue to poison the team and the project.  What hopefully is a small issue when you first identify it, can not be allowed to grow in to a show stopper issue that has the potential to disrupt the entire project.  Remember, you've been placed on this project to see it through, not to sit on the sidelines and watch it fall apart.

How do you handle disruption within your projects?

Tags: SDLC, Project Management, Project, Management, Conflict, Resolution, Project Manager, Software Development Lifecycle,  Project Lifecycle

For more information on David L. Collison: LinkedIn Profile