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

Plan for Success ... Be Aware of Reality!

I run hard! My teams run hard!  We’ve got a lot on our plates and the pipeline is overflowing.  As soon as something is done, there are 5 more things waiting in the wings that need attention.  That’s a good thing – it tells me that the business values the services that my teams deliver on and that we can continue to be a difference maker within the organization.

As we go about our business – we plan for success.  Delivering product and services that our Financial Institutions can use to succeed in the market and make a difference with their customers.  Over the last several years, we have built a process around activity that ensures that we know why we are building something, we know the success factors around what it is we are building and that we then can design, build and QA the stuff we are moving into our production environments.

The teams have done a great job of reducing the number of iterations built before code can move into production.  Translation, they’ve reduce the number of critical errors found during testing that requires additional iterations prior to implementation!  They’ve also significantly reduced the number of issues that require after hours support.  Our teams have worked together to reduce the overall amount of time needed to regression test our products.  We are doing automated nightly builds on our code and are well on our way to having a full suite of regression tests run along with the automated builds.

So why am I talking about all of this?  Well, to put it all in perspective, it doesn’t seem to matter how well we refine the processes and manage the activity, we still have things go wrong!

1. Requirements identified after development is under way. 
2. Designs between teams that sometimes conflict. 
3. Estimates of project activity that end up being woefully incorrect. 
4. Resource constraints across teams just based on the sheer volume of activity. 
5. Data issues within our test environments. 
6. Validation exercises that end up taking longer than planned.

You know the drill.  You’ve all seen similar stuff happen to your projects.  So what’s a team to do?  Well as much as we want to keep our rose colored glasses in place and see sunshine and rainbows, it’s our job as leaders and technical experts to measure and apply a dose of reality within our projects.  The organization is looking to us to deliver new features/functions into the production environment.  They don’t really care to hear about how we make the sausage or why it might be taking longer.  What they do want is a semi-reasonable date as to when the features/functions will be available and what it means to our Financial Institutions and our Acquirers.

So, translating back to our internal teams, that means we need to make reasonable estimates along the way and refine as we move through the process.  As technicians, looking at and identifying the tasks needed to complete the activity – you can’t assume everything will go the way you want and your estimates need to include the breathing room you’ll need when something unexpected pops its head up.  As project managers, you can’t believe everything you’re being told – you need to validate what is being said and ensure people are on track.  Depending on the complexity of the project, you may need to put in some buffer time between the various activities to ensure that the teams have time to stay on track and recover from unknown issues.  This may not be needed on smaller less complex projects, but as the complexity gets bigger, you’d better start thinking seriously about buffer space.

I am not advocating that you needlessly pad time into your projects to make a 6 week effort end up taking 10 weeks.  What I am advocating for is that project resources accurately evaluate their tasks in a realistic fashion and feed those numbers back up to the project manager – that includes identifying the riskiest tasks and ensuring that you’re not being overly optimistic on the estimates.  Additionally, the project manager needs to review those estimates coming in and ensure that the numbers are ‘good’ and make judgements on where additional time may be needed to address parts of the process that look to be difficult.

I’ll give you a perfect example within my own organization.  With our large enterprise wide projects, we perform an integration test within development prior to moving the code into our formal QA and Parallel environments.  We began this formal ‘integration’ test effort probably a year and a half ago.  This testing required us to ensure mock data was setup across various platforms and application silos that would allow us to take transactions across the entire ecosystem.  This was initiated to ensure that by the time the code hit QA that we had successfully tested input/outputs and application handoffs between the various silos.

When we initiated this new step in our overall lifecycle – we were extremely aggressive in how long we thought it would take us to build the environment, populate the environment with the correct data and then execute the integration test plan.  I kept pushing the team to get all this activity done within a short time window so that we could then get into the ‘real’ testing and move the project forward.  Whether planned or not – the time associated with this integration testing took longer than planned and we eventually had to account for that within our planning.  Now that we’ve been through several iterations, we are beginning to automate various pieces of the environment and data setup/configuration – this should help us draw the time back down

Our goals were right, this helped us implement code into production that had a higher level of quality, however, I created a set of false expectations within the teams on the durations associated with this activity and they needed to give me feedback to reset my expectations and identify the correct timeline within the overall project activity. 

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

It's NOT all about you, it's about the Team!

I'm not a success without the people on my team!  Flat and simple - if they aren't succeeding, then I'm failing.  As a leader inside the organization, it's one of my responsibilities to look out for the needs of my team and find ways to make them successful.  I can't guarantee them success every time, but I need to find ways for them to succeed more than they fail and within their failure, I need to recognize that I own some of that failure.

I've seen people that have been great contributors on the team suddenly put themselves in a position where they look like they are going to hit the wall.  I've had to step in-front of them and prevent the smash up that is about to occur.  Sometimes these discussions can be difficult, because they don't want to admit that they are about to fail.  Sometimes there is a look of pure relief on their face when someone steps in and says - hey, I'm here to help.

One of the first projects I worked on after becoming a manager was a fairly mundane project needed within the organization - there were several pieces of the software being developed and one of the pieces was being held up because there was nobody else to work the issue.  I made the decision that I would jump in and work the issue myself.  At this point, my boss asked me why I was working on the code.  I explained to him my logic and he began to ask questions:

• If  you're working on the code - who's going to keep track of all the pieces that are moving within this effort and make sure overall we're on target?
• If you're working on the code - who are your engineers going to escalate the issue to when there's a problem and how will you manage those issues?
• If you're working on the code - who's going to keep myself and the rest of that management team aware of the status, issues, risks and plans?

There were several other questions - but you get the general sense of the conversation,  I was young and eager and for every question he had, I had an answer, me!  My manager made it clear to me that this was not the right answer and that I was going to end up hitting the wall.  I assured him, that I would be able to handle all of it and went on my merry way.

Soon, I began to trip up on myself - at first it was missing a status report here and there, not escalating an issue that needed to be escalated.  Then the impacts grew - I wasn't paying attention to all of the different moving parts and coordinating the delivery.  I hit the wall.  My boss looked me in the eye and asked me what I was going to do to clean it up.  I had failed!  Luckily, he reached out and helped clean up the mess and get the project back on track.  But what he taught me happened after all the pieces had been put back together and the project was again running forward.  He sat me down, told me that this time he had allowed me to fail and had helped me out so that I could learn what not to do going forward!  The next time this happened, if I let it happen, I would need to clean up the mess by myself.

Where to start?  First I learned as a manager, it's tough to be the one in the details and still be the one coordinating everything else that needs to be done.  Two, I learned that sometimes it's alright to let people fail.  Three, I learned that when somebody does fail, you have to be there to pick them up and help them get back on track - give them the ability to learn.

Now in some instances - the failures begin to outweigh the successes and you come to the moment of truth.  Is there a way that I can make this person successful, or have they proven that they are incapable of performing within the role that they've been hired for - a difficult decision.

As leaders - either formal supervisors/managers or informal project managers - it's not enough just to do the tactical parts of the job.  It's essential that we work work with the people we touch in the organization and help lift them up.  Only if we truly give them the tools and skills they need to perform their role and prepare them for more difficult responsibilities in their future, will we reap the rewards and succeed within our own role.

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

Estimates - The Buck Stops with You!

Why are people so uncomfortable making a decision?  I admit I scratch my head frequently at some of the issues that land on my plate because someone was uncomfortable making a decision – or because they feel they haven’t accumulated enough information.

This is not a phenomenon unique to my current organization.  I’ve seen it across most organizations that I’ve worked in.  Managers have engrained into people that they are not allowed to make decisions and that they must review everything prior to anything getting done.  YIKES!  And then we wonder why people fail!  Better yet, we wonder why people leave us and move on to a new job – leaving us to spread the workload around to others on the team.

Look, I won’t claim my teams are exempt from this pattern.  But I do try to encourage people to think through problems they are facing and if they are unsure of a direction, at least bring options into the conversation when we sit down to have a discussion.  This at least allows me to see that they have thought through the problem and are attempting to address the issue.  Usually through conversation they’ll come to some type of a conclusion, thank me for the discussion and head back out.

I think where we struggle the most within my current teams is getting people to make estimates on project activity.  This is a personal decision by team members measuring how much work they will be responsible for against requested project activity.  When we first introduced this concept, there was a lot of push-back.  And to be frank, there were a lot of errors in the initial estimates.  But over time, people have grown more confident and are estimates are aligning better with the actuals that we measure over the life of a given project.

We go through regular training with people that are new on our teams.  It really doesn’t matter if they’ve been in development or whether they are new to the ropes.  Most developers have never been trained on how to produce reliable estimates.

So how do you pull together an estimate – well, for one thing, it’s different depending on what stage of the project you’re in: 

1. Discovery Phase: Usually estimates at this stage are done by someone within the management chain along with senior level technology resources.  How?  Well, the truth of the matter is the project scope is looked at in comparison to other projects that have been completed that smell like or look like they have similar impacts.
2. Requirements Phase: Typically this is a minor refinement of the estimate that was given in the Discovery Phase.  Any changes to scope are accounted for and typically there are additional details highlighted that point to previously unconsidered impacts.
3. Technical Design Phase: Now we are putting some meat on the bone.  At this point, technical resources have engaged and identified impacts across current systems/application silos and have also identified where new functionality must be created.  Along with the technical estimates business teams have assessed impacts to current and new processes.  Between the two paths, the full project estimate is considerably more accurate than anything that was put together in the first 2 phases of the lifecycle.
4. Development Phase: Some organizations perform the final detail design in this phase.  If so, this is the last chance to update those estimates both from a technical and business perspective.  This should allow the resources that are going to do the actual work to review the technical designs, identify the specific chunks of code or the business processes that are going to change the final say in what amount of time is necessary to complete project activity.

Rules of the road when it comes to performing estimates:

1. If you’re implementing new technology into your current technology stack – maybe you also need to set aside time to install and integrate the technology.
2. Don’t forget process changes.  Sometimes these changes can be just as critical to the project timeline as the technology changes.  Don’t underestimate the impacts these can have across your teams.
3. Don’t forget testing – and I’m not just talking about QA.  I’m talking about Unit Testing, Integration Testing, Parallel Testing, Performance Testing, Regression Testing, New Feature/Function Testing, and UAT Testing.
4. Don’t forget implementation planning and actual implementation activity.  While the universe may have been created with a big bang – in most instances you are going to see implementation activity spread out over a period of time.  Some implementation activity begins before the code touches production, and some activity happens months after the code is in production – you need to account for all of the activity.
5. Don’t forget to provide a buffer for 3^rd party activity.  I have yet to see a 3^rd party engagement go off without some type of change that has to happen.  The initial timeline provided for the engagement never usually is achieved.

Items for consideration when building the estimates:

• How many screen modifications need to be made?
• How many new screens are there in the project?
• How many web services need to be modified?
• How many new web services are there in the project?
• How many reports/data extracts need to be modified?
• How many new reports/data extracts need to be created.
• How many tables/stored procedures need to be modified?
• How many new tables/stored procedures need to be created?
• How many 3^rd party apps need to be touched?
• How many new 3^rd party integration activities are needed?
• How many processes need to be modified?
• How many new processes need to be created?
• What infrastructure changes are needed – servers, server types, routers, switches, security devices?
• What new infrastructure pieces need to be installed – servers, routers, switches, security devices?

Realize that you’re first efforts are going to be wildly off base.  Don’t be afraid to tell your team that you’re giving them time to get better at creating estimates.  This means when they’re wrong – it’s a conversation not a point against them in their annual review.  Use each estimate as a coaching opportunity when the final numbers come in – what they did right and what didn’t look so good and how do we make it better.

This by no means covers it all, but points you in the right direction.  Now I’ve heard some people say that in an Agile process you don’t need to worry about this.  Yeah, right.  Trust me, someone in the organization is telling the CFO what this thing your building is going to cost – how many 2 week iterations it’s going to take to get full functionality.  If you’re not responsible for making those conversations happen today – you will be at some point.  Better to start figuring this out know, before you’re asked to provide that first estimate.

Realize that you’re first efforts are going to be wildly off base.  Don’t be afraid to tell your team that you’re giving them time to get better at creating estimates.  This means when they’re wrong – it’s a conversation not a point against them in their annual review.  Use each estimate as a coaching opportunity when the final numbers come in – what they did right and what didn’t look so good and how do we make it better.

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