Adding Value – That’s Why They Hired Us …

Are you adding value?  I don’t care what your role is within the organization – are you adding value?

If you’re simply holding the fort, doing only the minimum required for your role.  Then you have a job, not a career and I would also argue you are not adding value.  Look, we are all here for a purpose and that’s to advance the cause.  Now for some, that may mean exceeding the expectations of the department down the hall, your peers halfway across the world or the customer actually using a product sold, distributed or given away by the company.  Heck, you may look across the deliverables of the team you work with and identify multiple customers.  At the end of the day, look back at what you’ve accomplished.  Did you move the ball forward and did you exceed the expectations of your customer.

If the answer is no – then you need to look at the way your performing your role, the way that your team performs it’s role and potentially the way that the company responds to its customers.  You can definitely change the way you respond to work assignments that you have responsibility for and you have influence on the way that the department and the company provides the product or service that your customers use.  Some of the best advice I ever received in my years of work: “under promise and over deliver”.  And, that’s not an excuse for padding the work estimates just to make yourself look good!

Early in my career, I not only took responsibility for work that was assigned to me, but I would volunteer to help others, or to take on additional work.  Now, all in all, that is not a bad thing, except for the fact that it was preventing me from meeting the deadlines associated with work my boss was expecting me to deliver on assigned projects.  Lucky for me, I had a boss that realized I was young; he knew what was happening and took the time to educate me on what I was doing to myself.  For a while, I kept up the pretense that I could handle the work – both my own and any additional work where I had volunteered.

Then the backlog started to creep in and I began to miss deadlines.  First I would miss them by a day or two and then it began to stretch out further.  Finally, my boss called me on it and forced me to admit that the additional work was preventing me from meeting my own goals and was impacting not only myself, but the entire team.  Not an easy conversation to have with your boss.  This is the person that I wanted to impress, to show him that I was the go to person on the team.  Well, I impressed him, just not the way that I had intended.

It took me a while to dig out of the whole that I had made, but my boss was patient and helped me make decisions on where volunteering to take on additional tasks made sense and where I needed to pass.  Sometimes that meant telling my co-workers that I was on a deadline, but that I’d be happy to help them once I got past the next milestone.  My boss made me realize that sometimes the person asking for help didn’t necessarily need it that minute.  Sometimes they could wait, and I needed to be able to determine when someone truly needed immediate help and when it was something that could wait. 

He also made me realize that it wasn’t necessary to volunteer for every extra assignment that popped up on the radar.  When picking these extra assignments, he showed me how to identify those projects that would have a net positive impact on the team or the company.  He also got me to realize that not every call that came in to my desk was an emergency. 

Now, I’m not advocating that you ignore requests.  What I’m talking about is being able to prioritize the work requests – both requests originating from others and additional work that you identify as important.  The feeder that fills your pipeline has many inputs – assigned project activity, departmental meetings, service requests, code defects, project meetings, code reviews, implementation planning, environment builds, etc.  However, there is only one output from your pipeline – you must be able to identify the priority of all of the inputs.  Now, depending on where you are in the chain of command, you may need to validate the priority with your boss, or you may be able to set the priority within some discretionary limits.  Whatever method you need to use – use it!  Figure out the priority and then work accordingly to produce results.  Meet the deadlines, exceed the expectations by delivering something extra that wasn’t planned and ensure that you wow your customer!

When it is something that you have direct control over – hold yourself accountable.  When it is a team or company decision, make your best case for change and don’t give up.  Just because someone up the chain doesn’t like the idea right now, doesn’t mean they won’t like it a month from now.  If you know it is the right thing to do, find a different way to present your idea.  You may need to find out why it was rejected and then provide alternatives that work around the objection.

Take a minute and think about a time you received exceptional service from someone.  Maybe it was the last time you went out to dinner with your family.  Maybe it was the last vacation you went on.  Maybe it was work that a vendor had performed for you.  Maybe it was a contractor that had worked on your home.  Whatever that moment was – what made it special?  Was it the personal contact?  Did the person responsible, go above and beyond and exceed your expectations?  Now, what can you do to provide that same experience for people you work with on a day to day basis.

So, how are you adding value today?

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

Using Metrics Across the Development Lifecycle

We’ve discussed metrics before, but I think it’s time to revisit the topic.  Different members of the team are going to want access to see different sets of metrics at different points in the cycle.  I think it’s critical for organizations to understand what metrics are easily available – or what can become available with a small amount of work.  Then you need to understand how to use the metrics to drive the behavior you want within the organization.  Metrics used the wrong way can create bad behavior.

I’ve known organizations in the past that rate their development team members based on the overall number of lines of code that they create.  I’ve attempted to explain to individuals that this encourages developers to focus on the wrong thing – how fast they can key in chunks of code without any care as to the number of bugs they are introducing into the application.  This may also encourage the development team to create chunks of code that are not optimized.

You may not think this is a big deal.  But I’ve seen real instances where a company has a transaction loop that is measured in milliseconds, just to have their transaction time crater because some joker hasn’t optimized their code.  Instead of being able to handle a 1000 transactions a second, they find out they can handle less than 10 transactions a second.  Yeah the guy got the code done ahead of schedule, but at the cost of preventing the system from processing transactions.  Don’t worry.  The change never saw the light of day.

I’ve also seen organizations that award bonuses to team members by how early they can deliver the functionality – a sliding bonus based on how early the product is delivered to production, the earlier you deliver, the bigger the bonus.  This shifts the focus to how fast the system can be assembled vs how well the system matches up to the original requirements or how many bugs found their way through to production.  Just a tad short sighted if you ask me.

Tracking metrics is a fine line.  You want to create a set of metrics that allows you to understand what is happening within your lifecycle, but you need to identify and balance the metrics to get the real behavior you want from the team.  Ultimately, you need to produce a product or an enhancement to an existing product from the project that is as free of bugs as possible and that delights the customer.  If you do your job right, you’ll deliver more than the customer was expecting (under promise and over deliver).  Oh, and you'll also produce a product that drives additional revenue to the organization.

NOTE: The metrics identified below are things that I’ve seen work across the various organizations I’ve been involved with over the years.  These may or may not work for your organization.  It is important to look at the culture of your individual organization and identify what you value, what needs to be measured and how that information will ultimately be used.  Do I use all of these in the role that I currently play – no.  Some of them just don’t make sense for the way that we manage our projects and others won’t work because some of our processes haven’t fully matured.

I've seen organizations use multiple specialized roles to get through the first couple of phases of the life cycle - variously titled: Product Managers, Product Owners, Business Analysts, Process Engineers, Product Engineers ... the list could go on and on.  That said, all of the roles have the responsibility to reflect the needs of the project sponsor.

Through the scoping/discovery phase of a project, the team should be fully focused on eliciting the needs and expectations of the Sponsor.  This allows you to draw the box around what needs to be delivered and to begin to identify what will be called success.  All that said, how do you measure the success of these individuals - what metrics make sense?

The Project Office may consider the project a success if it is delivered on-time and on-budget.  However, the Sponsors perspective is more concerned about the impact that the project has post implementation.  They would not have authorized the project to move forward unless they were expecting efficiency improvements, cost reductions or revenue increases.  Ultimately, the project was approved for some underlying reason.  It was not approved to provide busy work to a bunch of people across the organization.

From the Project Office perspective, the key metrics that they will watch - again remember they are concerned about time, costs and resources - occurs during the overall life cycle of the project.

1. What is the % of Project Change Requests against the identified scope that do not alter the overall boundaries of the project – minor misses?
2. What is the % of Project Change Requests that increase the original scope of the project enlarging the overall boundaries of the project – major functional or non-functional pieces that were missed – major misses?
3. Did they miss the target milestone to complete all activity associated with this phase of the lifecycle?

From the Project Sponsor perspective, the key metrics that they will watch will happen after the project is considered complete and has been moved in to production.

1. Did the company achieve the expected efficiency improvements, costs savings or revenue increases?  Does the project meet the objectives identified and agreed to within the business case?
2. Did the company hit the objectives for the total number of clients adopting the solution?

NOTE: Take a moment to reflect on the different viewpoints – the Project Office may consider the project a success due to the fact that it was delivered on-time and on-budget.  However, six months to a year later, the Project Sponsor may declare that the project was a failure because the expected increase in revenue didn’t appear.  What processes do you have in place to support the different needs of the Project Sponsor vs. the Project Office?  What feedback do you give to your Product Owner? 

As the project moves through the formal requirements definition phase, responsibilities shift and additional resources are brought into the team.  Additional artifacts are generated – the business case, requirements, business impacts, security assessments, risks and mitigation plans.  Quite a bit is going on in this phase and this really begins to put the underlying structure in place that will give shape to the product that is being built or enhanced.

The Project Office will have primary interest in the success of this phase and may want to look at measuring success of the team when the phase is complete based on the following metrics:

1. What is the % of Project Change Requests against identified requirements – minor misses?
2. What is the % of Project Change Requests that introduce new requirements – major misses?
3. Did they miss the target milestone to complete all activity associated with this phase of the lifecycle?

There are multiple team members defining requirements – one individual should be accountable for the overall set of requirements, but accountability should occur across those responsible for contributing to the set of requirements impacting their slice of the organization.  You may want to track down to the contributors so that you can assess weakness across projects and across the organization.  For example, you may see a pattern emerge across several projects that would indicate that requirements associated with the sales team are consistently seeing change requests – you then have something to act on.

As the project moves downstream we begin to do the formal design work – this is where vision hits reality.  The team gets larger and begins to focus on breaking down requirements or combining requirements to understand what is being requested and translating that into technical terms that define what will actually be delivered.  If the Project Sponsor wants a hard dose of reality – this is usually the place and time for that cold water to be thrown in their face.  Sometimes what is wanted can’t be delivered – or at least can’t be delivered without significant pain.

All that said, the design is laid down and the Project Office needs to measure the success of the design using the following metrics when activity within the phase is completed:

1. What is the % of Requirements that can’t be traced through to the Design – major misses?
2. How many defects are identified in production that can be traced back to Architectural Design?
3. How many defects are identified in testing that can be traced back to Architectural Design?
4. How many changes are identified within the architecture artifacts during the following phases of the lifecycle?
5. How many additions to the architecture artifacts are identified that account for functionality missed during the design phase?
6. Did they miss the target milestone to complete all activity associated with this phase of the lifecycle?

Then we are move into the construction phase of the life cycle.  Once again, the team bulks up and this is where we lay down the pieces that come together and satisfy the original vision.  Traceability becomes an important factor across multiple disciplines in this phase.  I like to include regression testing in this phase as my teams are moving to an automated nightly build/test model.  The Project Office may want to look at the following metrics after the phase has finished:

1. What is the % of Requirements that can’t be traced through to the unit tests?
2. How many defects are found during integration testing?  Are they design or build related?  
3. How many defects are found during quality assurance testing?  Are they design or build related?
4. How many defects are found during user acceptance testing?  Are they design or build related?
5. Did they miss the target milestone to complete all activity associated with this phase of the lifecycle?

We're almost there folks!  We now move into the formal testing phase - formal quality assurance, user acceptance tests, load testing, parallel testing.  This is all the stuff we need to do to make sure the product is ready for prime time.  The Project Office will look at this activity and want to track a few more metrics once this phase has been completed:

1. How many defects are found in the production environment?  Are they design or build related - or are they related to the implementation?
2. Did they miss the target milestone to complete all activity associated with this phase of the lifecycle?

If you review the metrics identified at each stage of the lifecycle, you'll see that most of these metrics assess issues that can impact the final product delivered to the customer.  The one consistent measurement across all phases that the Project Office will want to know about - but is not necessarily tied to the user experience is: "Did they miss the target milestone ...".  This is more about keeping accountability within the overall team to ensure that things stay moving.  And the most important metric won't be known until after the project is in production - are the customers accepting the product, is the company experiencing the revenue increase expected or the efficiencies that were planned.

Tags: Project Management; Software Development Lifecycle; Teams; SDLC; Change Management; Portfolio Management; Project Portfolio; Project Metrics; Metrics;

For more information on David L. Collison: LinkedIn Profile

Are we asking team members to be too perfect …

This happened early in my management career.  And, it’s a story that I share with others on occasion.

So, to set the background up, this happened a long time ago in a career far, far away.  I was a partner in a consulting firm and we were beginning to grow.  We had recently moved in to our own space and had begun to hire our first few employees. We had a set of clients that used us regularly and we continued to add new clients at a regular pace.  The company was profitable and my partners and I were working hard to keep everything running smooth, our customers happy and our bills paid.

One of my hires, we’ll call him Tim, happened to be fairly fresh in to the game of programming, but he’d had a couple of years’ experience so I felt comfortable that he’d be able to handle moderately complex development assignments.  I ended up assigning Tim to a smaller project associated with a system that we had already developed for one of our primary clients. The add-on was to be done in MS-Access. And, yes, at that point in time, MS-Access was a go to tool for small database work.  The core system had already been developed and was being used by the Human Resources department.  The add-on piece would allow them to track additional data associated with training that they provided their employees.  This was critical to the HR department as the company was responsible for providing proof of training to several of their clients to keep contracts in place and active.

So, I assigned the new hire this add-on to the core system.  I attended meetings with the client, along with Tim, and acted as the Project Manager for the development effort.  We met with the client weekly to provide status reports and to get feedback from them on our development plans and activities.  After a few weeks, it became apparent that Tim was struggling with the development and was not making the progress that was needed on the project.

After meeting with the client one afternoon, Tim and I headed back to the office.  I knew it was time to address the situation and so when we arrived at the office, I asked Tim to meet me in the conference room.  Tim knew I was agitated and he immediately became defensive.  My mistake as a young manager was letting my emotion show through during the conversation. Instead of talking to Tim about the roadblocks he was facing and how we might overcome them, I made the mistake of attacking him.

Luckily, during the conversation we both realized we were not approaching the conversation the right way. It actually happened when he caught me between breaths and asked me, “What do you want me to do, quit?”  He stopped me dead in my tracks.  No, I didn’t want him to quit, I wanted him to do the job and I told him so.  At that point, we began to backtrack and talk about the issues he was facing and what we needed to do to dig out of the hole.

Long story short, all he needed was some technical mentoring.  I was so busy selling our services to new clients, attempting to PM projects and doing my own development tasks, that I forgot that I needed to reach down and help the next person up the ladder.  I compounded my mistake by approaching Tim the wrong way and not giving him the opportunity to find a way forward.

Tim actually ended up being a fantastic team member.  He was a hard worker and knew how to interact with clients.  I’m glad that he stopped me during our conversation with his question before my emotions got the better of me.

Sometimes we need to realize that the people we’re dealing with don’t know how to succeed and it’s our job to show them.  We can’t ask them to be perfect every minute of every day.  Think back on the mistakes you’ve made in your career.  If someone hadn’t extended a hand to you, would you be where you’re at today?  The real nut is, are they learning from their mistakes.  If they are – then mark it up as a win!

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

Communicate Early and Often: Real Lessons for the entire Team!

I’m often asked, “What’s the one thing that makes the difference between a successful project and a failed project.”  In my honest opinion, the success of a project comes down to communication.

Yes, there are all sorts of other things that can make the difference between success and failure, but I think the root of most of those problems comes back to communication.  You can diligently move through the lifecycle or through your sprint, you can create all of the project documentation and artifacts that you want, you can create pretty gantt charts to show the team, you can track all of the money spend and forecast future expenditures, you can track all of the defects and their remediation plans, you can check off all your milestones, however, none of that will make a difference unless you are communicating properly up through the project hierarchy and across the project team.  And, yes, there are two very different communication paths – each seeking their information.

The first path is the tactical path – cross communication between the people responsible for the day to day activity within a project.  These are the hands on people, making the product, building the processes, and changing the way things work.

The second path is the governance path – communicating up through the management chain to the sponsor.  The sponsor is the owner of whatever is being delivered, and ultimately owns the decision of whether to keep on working the project, rework the project if the results aren’t up to spec or to abandon the project.

Both communication paths are critical and if team members don’t support the communication strategy – you’ll be doomed to failure.  Don’t get me wrong, you might ultimately get your project into production, but you’ll have spent more money and your timeline will most likely have suffered due to rework, or you’ll have delivered the wrong thing.  And you’ll know it when people avoid using what you’ve built or it quietly gets shoved into a trash can somewhere along the way.

Let’s start at the beginning …

Who’s the Sponsor for your project?  Are they clearly articulating the vision?  Are they controlling themselves and others as it relates to scope?  Are they plugged into the project?  Do they know the major risks and mitigation strategies?  Do they understand the overall budget and do they know if the team is on track to meet or beat the budget?  Do they give guidance when the team is up against an obstacle that they can’t solve on their own?  Do they clear the roadblocks in front of the team? 

Or, do you find yourself learning new wants/needs every time you say hello to the sponsor?  Are they ignoring the risks the team has identified?  Are they unattached – do they really care about what is going on in the project?

What about the Project Manager?  Is your Project Manager setting expectations up front?  Are they letting you know how often you’re going to meet as a team?  Do they do frequent stand-ups to get the quick status checks?  Do they communicate regularly and update you on the status, risks and mitigation plans?  Is the Project Manager holding people accountable to deliver what they said they would, when they said they would?  Is the Project Manager tracking against the budget and keeping the Sponsor in the loop?

Or, does anyone actually know who the Project Manager is?  Did they set clear expectations for the team at the beginning of the project?  Did they communicate who owns what pieces?  Did they explain how often you would meet and what the format of the meetings would be?  When was the last time they talked to you about the pieces you own?  Do you know how the other pieces of the project are coming along – will they be ready when you’re ready?  Is the Project Manager out removing obstacles and ensuring that you can stay focused on your job?  Is the Project Manager providing you the details you need to know whether the overall project is on track?  Are they ensuring that decisions made are being distributed across the entire team?  Is your Project Manager checked out?  Do you see the Project Manager only when something is going wrong and they want to point the finger and redirect the blame?  Is the Project Manager in reactive mode only dealing with issues when they become critical?

And let’s not forget the team members – are they keeping everyone in the loop on the most recent changes to the schedule?   Do they immediately notify team members and the Project Manager when they see a risk that might affect the project down the road?  Do they escalate an issue when a vendor is not delivering functionality within the timeframes identified?  When they identify an issue, do they also provide potential solutions to resolve the issue or catch backup on the timeline?

Or, do they ignore the entire team when they have hit something unexpected?  What about when a requirement changes, any notice from the BA?  Whoops, did that interface change?  I’m sorry – didn’t you know that I won’t have that done?  Oh, that decision on the pricing has changed, didn’t you get the update?

None of this is rocket science and it doesn’t take someone with a masters or a doctorate to figure out what the issue is.  Get up out of your chair walk down the aisle, take a right and let someone know!  Use your scrum meetings to share issues/concerns with the team.  Let them know when something has gone off track.  Instant message the Project Manager – trust me, they want to know.  Pick up the phone and let someone know that something in the market place has shifted and the sales projections need to be updated.

Part of being a team means that you’re making some commitments – these are not optional:

1. Be accountable for the work you are supposed to complete.
2. Listen to other team members in project meetings – that means you won’t be checking your email or browsing the internet.
3. Be an active participant in project meetings – interact with team members and move the ball forward.
4. Share your knowledge with other team members – lift those around you.
5. Provide a regular status – you need to agree on what regular means.
1. As a team member that may mean daily.
2. As a Project Manager that may mean weekly to the Project Office and biweekly to the Project Sponsor.
6. Immediately communicate risks or issues with mitigation plans as soon as they are known to the Project Manager.
7. Immediately notify the Project Manager and other team members when you know you’re not going to be done with your assigned piece on time.
8. Be a problem solver – when others identify issues, be willing to help find solutions.
9. Be flexible – we all know things change, be the one to find the way to address the change.
10. Be respectful in how you communicate and interact with others, be supportive when needed.

I’m not saying this is going to fix everything that is wrong with the projects you work on.  I am saying it will make things go a lot smoother.  We need to trust each other enough to be open and honest with each other.

Tags: Project Management; Software Development Lifecycle; Teams; SDLC; Change Management;

For more information on David L. Collison: LinkedIn Profile

When Actions Fail To Match Promises – The PMs Nightmare

We’ve all had those moments when we finally realize people on our projects aren’t living up to the promises that they’ve made.  Ugh …. Can’t we all just do our jobs!   Apparently, not!  The real question, what are you going to do about it?

We all make promises in our lives – to our wives, our children, our parents, our bosses, our teams.  It is part of life; it is part of our character.  Sometimes these promises are small; sometimes these promises are the difference between a company meeting its goal and failing.  Unfortunately, we don’t always live up to our promises – sometimes it is minor, sometimes it can really screw things up.  And, like it or not, it’s your job as the Project Manager to hold people accountable.

One saying that was drilled into me by one of my bosses was the phrase, ‘Under promise and over deliver!’  In short, take time to think through what is being promised and ensure that you give yourself enough time to deliver a quality solution – then when there is agreement on what and when you will deliver, beat the expectations.   Find a way to deliver early or to deliver more than what is being expected.  Or better yet, find a way to delight your customer by delivering more than they expected ahead of schedule!

Unfortunately, life happens and occasionally we end up running into a wall when unexpected bumps send us off the path we were expecting to travel.  Whoops, didn’t realize that the changes were impacting several other applications that rely on this particular chunk of code – now I have to test a whole lot more than I was ready to test!  Whoops, who knew, the vendor that was going to install the new server got delayed and won’t be here for another two weeks!  Whoops, I thought it was only going to take a week to code that new service, it’s really going to take a week!  Whoops, I just figured out – I’m not getting full requirements and now I’m going to have to spend some time documenting what really needs to be done before I can actually start the design and coding, that’ll be at least a month delay!

As a Project Manager you’re going to hear every excuse under the sun.  There will always be a reason for why it didn’t get done!

First, you should never be surprised – in fact, if you’re doing your job right, you’re probably going to know things are getting off track before other people on the team are willing to admit that there is an issue.  How?  Simple, communication!  Remember, in past posts, I’ve talked about the concept of walkabouts?  This is your most valuable tool as a PM – walking around talking with people, 1-to-1 video conferencing , instant messaging, or phone calls.  Stay in touch with what people are doing – when approached casually, they will usually tell you more than when they are sitting in a status meeting.  It’s easier to share when they’re talking alone with you!  You can use this time to verbally catch up on what is being accomplished and most importantly, to talk about what issues they are facing.  What are the things that are standing in their way?  Are they seeing any delays in the stuff that is working its way through the pipeline that is supposed to be used to help them get their assigned work completed?  If so, who or what is causing the delay?

Then, don’t over react!  Don’t punish the person that is giving you the news – otherwise they’ll stop!  Find the root cause of what is causing the delay – 9 out of 10 times, it’s not what you initially thought.

Eventually, you will figure out what is really causing the delay.  Then you need to open up a dialogue with the individual responsible.

• Does the individual just need to be reminded of the need for the work that they’ve been assigned to be completed on time so that they next person in the workflow can do their piece?
• Can you talk with the team manager and get other tasks reassigned so that the individual has more time to devote to your project?
• Is the individual not staying focused and therefore delaying work on your project – spending more time than they should on Facebook, Twitter or the general Internet?
• Is someone intentionally attempting to derail your project because they don’t agree with the direction?

At some point, you’re going to run into a situation where the person does not want to cooperate.  Then you’re going to have to use your communication skills to get through the situation.  If you’ve never read the book, “Crucial Conversations Tools for Talking When Stakes are High, Second Edition”, by Kerry Patterson, Joseph Grenny, Ron McMillan and Al Switzler – pick it up today, or download to your iPad/Kindle.  This book is an excellent reference when faced with conversations that are going to be difficult.

The biggest ‘trick’ in the bag is to use the dialogue to bring all the information out in to the open and provide a safe path for both you and the other individual to have input into the solution.  It is driving to get results with and through the people you are dealing with on a daily basis.

Your goal is to understand what is driving the behavior of the other individual, then to ensure that the individual knows that you’re looking for a win-win way to move forward.  If you approach the conversation in the right manner, allowing them to share with you the issue and to be part of the solution, you will reap rewards.  Stop, listen, let them tell you their story and allow a little empathy to show through, then you can begin tackling the issue of how to bring the assigned task back on track.

Tags: Project Management; Software Development Lifecycle; SDLC; Change Management; Crucial Conversations;

For more information on David L. Collison: LinkedIn Profile