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

Agile? Waterfall? - Pick Carefully or Pay the Price!

Managing projects across an enterprise is an art as well as a science. There are several well known paradigms used by organizations across the world - waterfall to agile with variations in-between. I have always told those that have asked that there is not one silver bullet to magically solve the project management puzzle. In fact, my recommendations to people have always been to create a project management paradigm that fits the culture and needs of the organization.

My teams work in an industry that is heavily regulated by state and federal agencies and also must conform to several industry governing entities that set standards within the payments space. Many of the projects that we work on are implementing standard interfaces between the various payment networks, acquirer, issuers and other players within the financial industry space. Implementing these interfaces is a technical exercise with very little to no user interface. You either get the spec right or the money doesn't move. These initiatives really are not setup to be run utilizing agile techniques.

Now, let me shift over to some of the other initiatives we run within the organization. Our mobile and internet applications. As you can probably guess, these applications have significant user interfaces. These project efforts can utilize and benefit from agile techniques that can give our 'user representatives' much quicker access to potential solutions as well as drive increased cooperation between the development, user and quality assurance teams. This is a place where our teams are experimenting with agile techniques as a way to accelerate delivery through the development channel.

One organization utilizing different project management paradigms based on the unique needs of the initiative!

I'm running at this from two different directions at the same time:

1. I'm working with our project management organization to review our overall defined lifecycle to recommend changes that will allow projects that might benefit from being run utilizing agile techniques to take advantage of a slimmed down process.  We still need to figure out how to satisfy the documentation requirements of the various state/federal agencies and industry governing bodies, but overall, they are supportive of our desire to create multiple lanes that can be managed differently based on the overall risk of the effort.
2. I'm encouraging our project managers and team members to challenge the process. When working any individual initiative within the overall portfolio to make recommendations to skip various project artifacts, project steps or entire slices of the overall project lifecycle. The key is to document the decision as to why decisions are being made to skip certain pieces of the lifecycle based on risk and impacts to the overall effort.

This is what works in the enterprise that I currently work for. 

On a regular basis, I have to sit across the table from auditors and prove to them that all of the appropriate documentation has been generated. That there is traceability though the project effort from requirements, through design and testing. I have to show them our implementation and fallback plans as well as prove that those plans were followed during actual implementations. Our auditors will randomly pick projects and then go through all of the documentation and measure it against the documented lifecycle to ensure that it's all there. If something is missing, there has to be proof - either through project meeting notes or via change requests - that show the decision was made to skip the document/project step(s). This proof also needs to discuss the risk to the product, the enterprise, our financial institutions, acquirers and/or processors. It is the goal of our project management organization to manage these risk issues and ensure that we are safeguarding our ability to process payment transactions and move money within the payments space.

In past lives with other organizations I've run the gamut from running lifecycles that are even more formal than the one my teams currently use to running very informal lifecycles similar to the agile paradigm. The key is understanding the culture of the organization, the risk tolerance within the organization and the  time to market pressures within the industry.  As leaders within your organization, it's your job to discuss these issues and build processes that match the particular needs of your organization, manage the risk to the organization and your customers and build a project lifecycle paradigm that can deliver.

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

Don’t Hide Behind the Process

Well, it’s been a while since I’ve discussed process issues.  Time to dig in and have some fun!

Most of you that have followed my previous posts know that I’m a process kind of guy!  I’ve introduced formal lifecycle management into several organizations.  The teams that I’ve led have successfully utilized process enhancements to drive improvements in productivity, overall capacity and quality within various organizations large and small.  Utilization of a known process allows you to begin to measure various pieces of the lifecycle – looking for inefficiencies and issues that impact your overall ability to deliver for the organization.

Now all that said, each organization needs to find the lifecycle process and development paradigm that will work with their culture.  I’m not going to try and tell you what development paradigm you need to follow because I don’t know your organization.  Within the organization I currently work for we largely follow a waterfall process with some agile techniques utilized within various teams.  This works for us and the style of applications that we create/support – mostly technical interfaces within the payments industry.  Our overall lifecycle has various checkpoints/gating that we use to validate we are ready to move to the next stage.  This works for us!  We’ve significantly increased our productivity and capacity over the last decade and have improved the overall quality of applications that we are delivering to our production environment.

While all this has been good, I occasionally notice when people are hiding behind the process versus just getting the work done!  Not every project needs every step of the lifecycle.  Some are small enough and straight forward enough that we can skip various parts of the process or make the decision not to create some of the standard artifacts/documentation.

Decisions need to be made up front when the project is defined.  Those in the know, need to direct the teams when a project needs the full pomp and circumstance of the lifecycle and when the teams have the option to skinny up the process and skip parts of the lifecycle.  That means at the very earliest stages of Discovery, the Project Sponsor should be giving direction to the team on what the risks are associated with the project which can then drive decisions on how much of the process can or should be used on the project.

Additionally, once a project has been initiated, I think individual team members need to be cognizant of what is happening and make recommendations to the Project Manager if they feel certain pieces of the lifecycle could be skipped or maybe some documentation might not need to be created.  I’m not saying that we’ll always make the choice to skip over pieces of the lifecycle or to not create various pieces of documentation, but as leaders, we need to listen to the recommendations of the people closest to the work and if it makes sense, say yes!  When we decide that we can skinny up the process used within an individual project or that we can eliminate some of the standard documentation, those decisions should be documented.  That way, there is a record of the decision and the reason is documented and shared with the Project Sponsor.

Overall, we still need to deliver for the organization!  Delivering the requested solutions with the necessary features/functionality; delivering a solution at or below the expected budget; delivering a solution with the highest levels of quality.  Our teams should be held accountable to ensure we are delivering successful solutions at the end of the project.

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

Metrics - How I Use Today

Metrics are a funny thing - what works for one team may not work for another team.  In practice, I have always found that I need to adjust the metrics that I track based on the organization.  I find it humorous when some vendor walks in the door and tells me that if I just revamp my process to use their custom SDLC solution and manage by their key indicators that all of my problems will be solved.  Dream on!  If I’ve learned one thing, it is the fact that I must be sensitive to the unique culture of the organization and create a process and metrics that work within the overall organization.

So, that said, I’m going to walk through some of the metrics and processes that my teams currently utilize and how these get used to strengthen the overall lifecycle.  You may find some of this useful, or you may decide that the whole thing is nonsense.  That’s up to you - what I can say is it works for the teams that I manage and is trusted by the management team to give insight into our overall portfolio.  This is still somewhat high level, but it will give you the general flavor of the things that I consider important.

One of the first things that I did walking in the door was to have the entire development team begin tracking what time was being spent on what activity.  There were multiple reasons for initiating this type of tracking:

1. It allowed each individual developer and their manager to identify where they were spending their time.  It also initiated conversations on why people were spending time on certain activities.  Over a period of several months, we collectively managed to increase time spent on corporate approved projects from 35% of the overall time to 65% of the overall time.  We continue to look at this metric to ensure that people are spending time on approved project activity.
2. It allows me to understand how many hours people are working and to look at when I need to increase our headcount.  Over the last six years, I have used this data, along with other metrics information, to initiate the discussion on headcount increases and win those discussions.

Time tracking allows me to identify several metric points that provide insight into our overall lifecycle, as well as down to individual resource management:

1. Overall time spent on a given project across all resources.  How did it compare to our baseline estimates?
2. Time spent on activities within the project vs the baseline projections.
3. Are our estimates accurate?
4. Did we identify development activity that was missed during the design stages?
5. Individual time analysis - approved project activity vs production maintenance vs defect management vs administrative overhead.
6. Team analysis - approved project activity vs production maintenance vs defect management vs administrative overhead.

This has proven so successful within my team, that the entire IT Department now tracks their time and all individuals within the Business Teams track their time against project activity.

While time trackings helps at an individual project level and at a resource level - it is responsive and does not allow you to project out over a period of time.  For that you need a view into your entire portfolio.  To that end, we have a Portfolio Plan that is reviewed on a weekly basis by myself and my peers across the organization.  We do this to identify bottlenecks in the process, find ways to breakdown barriers and push the projects forward.  Here are the key metrics that we review:

1. Each project within our Portfolio Plan is broken into 6 distinct phases - Discovery, Requirements, Technical Design, Development, Testing and Launch.
2. Each phase has two key dates - Start and Finish.
3. Each phase has resource allocations assigned for each team.
4. At the end of each phase we adjust our timelines and allocations for the following phases based on what we’ve learned to date within the project.
5. Each project in the Portfolio Plan is tied to the associated “real” project housed in our MS-Project Server.
6. Each “real” project has standard milestones that identify the initiation of each phase and the completion of each phase.
7. Each day - routines are run that allow us to provide analysis of the Portfolio Plan vs what is happening within the “real” projects.
8. Periodically, I go in to relevel the entire Portfolio Plan to ensure that we are not over-allocating any one team and that we have enough work moving through the pipeline.

Why do we do this?  Simple, it helps us control the activity in the organization today and allows us to review the allocations of the various teams and ensure that we are levelling project activity over a period of time.  Most importantly, it forces us to prioritize what is moving through the pipeline.

1. I can tell when activity within any phase is going to be completed ahead of schedule, on schedule or is behind schedule.
2. I can use the above information to tell me when I need to reallocate resources so that I can hit internal target dates for critical projects.
3. I can use this information during budgeting to review with Senior Management and discuss our pipeline to see if they are ok with the volume of activity we are managing or if we need to increase our pipeline.
4. I can use this information to hold individuals and teams accountable.
5. I can project out when we will be trying to force through too much activity within the overall pipeline and use that information to initiate conversations about the priority of project activity.
6. I can use this information in conjunction with the time tracking data to identify when additional resources might be useful.

So, removing ourselves from the project level and going down to where the rubber meets the road, let’s look at some of the metrics that we are tracking within the development team as it relates to coding:

1. We have begun implementing nightly builds/nightly regression tests across all of the development teams.  Some teams are further along in the process than others, but all are moving towards the same overall goals.
2. Jenkins is used as the tool that automates all builds for all packages across all environments.
3. Jenkins is also used to gather results from the build process and the regression test process.
4. Jenkins is used to distribute emails to team members and management members identifying the results of the build/regression test process.  Developers are then responsible for going in and fixing the issues that have been identified.
5. Sonar is a tool that allows us to view the results of the build/test processes in a web application - broken out by each application.
1. Line Coverage - how much of our code has been validated with test cases
2. Unit Test Success - how many of our tests completed successfully, how many failed.
3. Violation of Rules Compliance - how many instances there are where code is not conforming to coding rules - both those identified as industry best practices and those that we have defined internally
4. Severity off the violation.
5. Code Reviews - I can tell if the code has gone through our review process.
6. Other metrics are provided - but I don’t consider them as useful as those identified above.

All of the above gives me insight into the overall confidence of the package before we move to production.  I can review this anytime I want and see our progress in knocking down the number of bugs being found by our standard unit and regression tests.  I can see if we are improving the overall amount of code that is covered by our tests.  I can see if we are reducing the overall number of violations that we are finding within any given application.

Moving in to the formal test cycle, I then begin to track a different set of metrics:

1. How many defects were found by QA that were not identified by the Development Team through unit, integration or regression testing?
2. How many new package builds occur before QA has a clean package ready for production?

Each week we notify the entire management team of changes impacting the 6 phases of our project lifecycle.  Those projects where dates have shifted for any given phase are identified along with explanations - a miss by the team, extended due to resource constraints, extended because we missed something, reduced because it was easier than we anticipated.  Whatever the reason, it is noted and everyone has visibility.

On a bi-monthly basis we meet with Senior Management to discuss the overall portfolio.  The slide in timelines - positive and negative - that we are seeing across all projects.  Projects impacted by levelling activities.  Reviewing the priority of projects so that we understand where to focus time when the pipeline is packed full.  Understanding shifts in strategy that we need to accommodate within the overall pipeline.

At the end of our projects, we provide summary information to our Senior Management Team that compare the total number of hours spent within the various teams vs the baseline estimates.  We report on the total $ expenses vs the baselined estimates.

Again, this is somewhat high level, but it gives you a flavor for some of the things that I consider useful as my teams move projects through the lifecycle.  Most of this was accomplished using tools we already had in place - but that we weren’t taking full advantage of:

• MS-Project
• MS-Project Server
• PWA
• Reporting Analytics
• Jenkins (Build / Test Automation)
• Sonar (Consolidated Build Reporting)

Yes, there are other metrics that we track and discuss.  This has all been done with an eye on improving individual and team productivity, reducing the number of errors moving through development and into QA (ultimately into production), holding individuals and teams accountable and ensuring that we are prioritizing activity within the organization to align with the overall strategy communicated from Senior Management.  I’m focused on those metrics that can provide significant results for the organization.  I’m not interested in adding metrics to produce pretty charts.

None of these metrics are full-proof and each must be taken at face value.  Sometimes the metrics lie and that’s where it is the job of us as individuals to interpret and validate the results.

Tags: SDLC, Software Development, Metrics, Lifecycle, Software, Application Development, Project Office

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

Metrics Do Make The World Go Round!

If you can't measure it, you can't fix it.  To be more specific, you need to be able to recognize those things that are slowing you down, interrupting the flow, introducing defects, raising costs and frustrating your team members.

Some things you can figure out just walking around, talking to your team and taking a look at what is happening on a daily basis:

1. Seeing that your technical teams are getting interrupted regularly and don't have time to concentrate on their assigned work.
2. Seeing that your developers are the only ones testing their own code before moving it into production.
3. Seeing that the project team is doing a lot of rework because nobody is willing to make a final decision.

At some point though, you'll have reached up and plucked all the low hanging fruit off of the tree.  Then comes the tough part.

Our processes can't remain static.  We need to look for ways to reduce the timeframes necessary to deliver products to production, instill a zero defect mentality within our teams, improve communication between teams, reduce the amount of time needed to regression test our code, and focus more of our time validating the new functionality.

This is where metrics come in to play.  You need to begin to identify the key data points within your cycle that you can use to measure/monitor.  Then you need to build in ways to capture those data points.

1. How long does it take to move through any one phase of your lifecycle?
2. How many elements require rework at any stage of the process?
3. How many times do you have to backup in the lifecycle?
4. How many defects, and what kind of defects, are found within the various testing - unit, integration, regression, parallel, or UATs?
5. How much of your code has valid tests that you can prove exercise the code?
6. How many defects are found after the code is moved in to production?
7. How much time is wasted with the project in non-productive time as you wait for various teams to be available?
8. How much of your teams time is being wasted on unproductive activity - non-project meetings, administrative activity, or unapproved development activity.

Now, the fine line is defining and being able to record these data points without impacting activity within the overall lifecycle.  What systems do you have in place today that are used within the lifecycle and can you augment these systems to capture the data points that you have identified and be able to automatee the analysis of the data.  There will be some level of manual analysis - but, I would recommend automating as much of this activity as possible.

How can you make the argument that you need to add new resources if you can't prove that your resources are saturated with approved project activity?  How can you make decisions on your test processes if you don't know where your tests are failing?  How can you hold your development team accountable if you don't know where their spending their time and how many errors are getting past them and in to the QA environment, or worse yet, production?

I'm not advocating that you immediately go out and measure create metrics across the lifecycle.  I do challenge you to think through your lifecycle and begin to identify the parts of the lifecycle that need adjusting and then think about the metrics that could be catured that would help you make decisions.  If you are totally comfortable with your entire process - then I would gather feedback from your peers throughout the organization, asking them what is and is not working, and use that information to guide you on where improvements could be made to your lifecycle.

Tags: SDLC, Software Development, Metrics, Lifecycle, Application Development, Project Office

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