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

Timelines - Not Just Something To Look At!

I've spent the last two posts discussing the role of the Project Manager - what I think is important for the Project Manager to do within the role that they play and how they not only need to manage the assigned Project Team, but also how they need to manage across and up thru the organization to be successful. Today, I'm going to switch gears and discuss one of critical items that the Project Manager owns.  The Project Timeline - for the purposes of this discussion, I am focusing on Project Timelines associated with the development of software.

Project Timeline Definition: The timeline consists of a series of interrelated tasks and activities within a given period of time representing the work effort needed to deliver some set of functionality in to the production environment.

We've discussed the overall Project Lifecycle in several previous postings.  For the purposes of speeding the discussion up, I'm going to assume that everyone is familiar with the stages of the lifecycle that I've discussed:

1. Discovery - defining the box around the activity of the project, documenting the goals of the project effort, the expected deliverables, potential costs and any deadlines that must be met.
2. Requirements - detailing both the functional and non-functional capabilities, features and attributes of the project deliverables.
3. Technical Design -  detailing the technical road-map (Technical Specification) that will be used to satisfy the identified requirements.
4. Development - the construction of the deliverable, including infrastructure and application pieces needed to satisfy the Technical Specification including both functional (user features) and non-functional (response time) items. 
5. Test - executing regression and new feature/function testing to ensure that existing functionality was not broken by the introduction of new features/function and that the new feature/functions work as expected.  Would also include load testing to ensure that the system performs within accepted time parameters.
6. Implementation - Activity associated with moving the new system in to the production environment.  This includes the code delivery, database changes, parameter file changes and infrastructure changes in to the environment.

Even with the simplest project, some combination of the above phases of the Software Development Lifecycle (SDLC) will be executed.  All of this activity combined together represents the Project Timeline.  From the very first discussions identify what might or might not be included in the final delivery to the actual implementation and post-implementation activity needed to validate that the system is working properly and that end users can begin using the functionality delivered within the project.

As stated in previous postings, not every project needs to follow every stage of the defined SDLC process or create every artifact defined within the process.  However, every project needs the minimal amount of ceremony and documentation necessary to ensure the success of the project.  More complex projects will require more ceremony - simple projects will require very little.  No matter the size of the project, there is still a start and finish date associated with the activity of the project.  Some organizations may not formally begin tracking activity on a project until it gets to the requirements stage, and that's fine.  Whenever you begin - you begin, and that is the start of your timeline.

So why is all of this important?  Well, first and foremost, the Project Sponsor and the management team are going to be interested in the overall timeline and how current progress matches up against expected progress.  In other words, how is reality matching up to the rosy picture that was painted at the beginning of the project?

Now, for the Project Manager to really manage the activity associated with the overall project, there must be reflection points where the team can evaluate activity done on the project to date and reassess the remaining activity to validate current expectations as it relates to the overall budget, resources and the Project Timeline.  Within the organizations that I've been associated with over the years, we have established standard points within the overall SDLC process where this assessment is performed and the results then communicated up to the Project Sponsor and the Senior Management Team.  In the organization that I currently work for, we formally handle this after each of the following milestones:

1. Requirements Completion: This is the first chance to validate the high level timeline initially envisioned when the Project was first initiated.  By this point everyone should understand what is going to be delivered, the touch points between the various systems/sub-systems, whether new infrastructure will need to be deployed and what testing/validation may be necessary.
2. Project Level Design Completion:  At this point the Technical Specifications have been generated and assumptions from the Requirements Phase have been validated.  Information needed to understand what 3rd party pieces need to be incorporated in to the delivery have been identified and initial cost-estimates are available, internal labor has been estimated and specific touch points between systems have been identified.
3. Detail Design Completion: At this point, the team involved in the construction of the system have been involved and taken the Project Level Design (Technical Specification) and turned it in to actual directions that the Software Engineers and Infrastructure Engineers will follow to create a system that satisfies the Project Level Design (Technical Specification) and ties back to the Requirements.  All activity/tasks related to the project have been identified and estimated.  All external costs have been confirmed.  All internal labor costs have been identified.

After the Detail Design Completion is hit, the Project Manager is responsible for establishing the final baseline.  To be honest, we currently are establishing baselines at each of these reflection points.  We are then using that information and feeding it back in to the teams to help them as they generate estimates for new project related activity.

At each of the above reflection points you are able to provide updated budget, timeline and resource estimates to the Project Sponsor and the management team.  This will be used to validate whether it still makes sense to pursue the project - or if the approval to move forward needs to be revoked.  

Why would they revoke a project that has made it this far in to the SDLC?  Any number of reasons:

1. The project no longer makes economic sense.  Initial cost estimates were too optimistic and did not account for all of the activity within the project, both internal and external.  Final labor costs or licensing costs may make the project unviable.
2. The Project Timeline does not allow the business to achieve the strategic goals associated with the identified deliverable.  Maybe the project had to be delivered by a specific date to beat a competitor to market and missing the date means missing the sales potential.
3. The defined deliverable no longer provides the competitive advantage necessary to gain in the marketplace.

As Project Manager, it is your job to establish additional milestones within each of the phases of the project to gauge whether the team is on track.   This also means looking at on-going activity within the project and the activity of individual team members to ensure that they are spending enough time on their assigned tasks to keep current activity aligned with the planned activity.

1. Did you allocate a resource full-time to the project?  Are they actually staying focused on assigned tasks and spending their workday on your project?
2. Was their a production issue that diverted assigned project resources?  What impact is that going to have on the overall timeline when they just spent the last four days resolving an issue for one of your largest clients?
3. Is activity on another project impacting the ability of assigned project resources to work on your project activity?  Your most senior developer has been stuck working an issue for the last 3 weeks on a separate project integrating code with a 3rd party who has been unresponsive.
4. An external party missed delivery of promised code or infrastructure pieces that are critical to the delivery of your project and they can't delivery the necessary functionality for another month.

There are a lot of things that will end up impacting the overall Project Timeline.  The Project Manager needs to continuously review current status against the plan and then work to remediate slippages identified within the overall Project Timeline.  Many times, the Project Manager will be able to do this without escalating up the chain.  However, some issues will require that the Project Manager escalate issues to the necessary resource manager, Project Sponsor, PMO, other management team members across the organization or the Senior Management Team for resolution.

How are you managing the Project Timeline within your organization?

Tags: Project Manager, SDLC, Project Management, Project, Management, Manager, Lifecycle, Software Development Lifecycle, Development, Software Development, Project Timeline, Timeline

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

Being a Project Manager - Part II

So, the last time we all gathered, I discussed the Project Manager.  We spent some time exploring the responsibilities of the Project Manager and dove in to things like planning, budget management, time management, resource management, risk identification and mitigation, quality, documentation and team leadership.  These traits and activities are important, but they are only one-half of the full equation.  If you look closely at the previous posting and the items just mentioned, you'll see that they point down or flow horizontally through the team and the organization to promote activity that will allow the project to succeed.

Managing down and across the organization is important.  However, there is one piece of the puzzle that I didn't mention.  And, those of you that have been in the business for a while, already know what's coming.  What was left unmentioned and what I'd like to cover in today's discussion is the fact that effective and successful Project Managers must learn to manage up!  Manage up?  Shouldn't the Project Manager be relying on senior leaders in the organization to act as their escalation point and provide cover when needed.  Unfortunately, the answer is more subtle than that - it is more of a yes and no depending on the situation. 

Any organization is full of politics.  Some organizations manage it better than others, but in any organization there is an underlying game that gets played.  And the Project Manager is left to ensure that the project gets completed within the constraints originally identified while trying to keep all the players happy.

1. First up in batting order is the Project Sponsor.  This is the player that went to bat to champion the project.  They fought for the priority, the budget and the resources to make it happen.  It's the Project Managers job to make sure that the sponsor is kept in the loop, has a proper understanding of what is and isn't in scope and how well the project is aligned to the overall timeline, budget and resource requirements.
2. Moving through the batting order we then go through the Senior Management Team.  Each of these individuals represent competing interests and will lobby to see project changes that benefit their slice of the organization.  Once scope is approved, it's the Project Managers job to maintain order and limit scope creep.  While there is always room for minor adjustments in the overall scope and project activity - it's the Project Mangers job to ensure that these changes do not impact the budget, timeline or resources.  Additionally, if the Project Manager feels the change is justified, then they must keep the Project Sponsor in the loop.
3. Next up is the Project Manager's boss and the Project Management Office.  They've set the constraints around all project activity and they are the keepers of the approved SDLC process.  They have the keys to the overall portfolio and the Project Manager must be sure to align project activity with all of the other company initiatives.
4. Then there are the Resource Managers.  The Project Manager has assembled a short term tactical team to execute against the overall tasks and activity of the project.  These resources don't belong to the Project Manager, they've been borrowed.  Their Resource Manager is going to want to pull them back at times to work critical production problems, fill in for a resource that is suddenly gone or for any number of other reasons.  The Project Manager will need to manage these diversions.

As you can see, life just got a whole lot more complicated.  In a perfect world, the Project Manager would never have to worry about things going wrong.  Unfortunately, for any project of any size, things will go wrong, contingencies will need to be identified and keeping everyone in the loop will become a necessity.

You have this particular job at this particular time due to the Project Sponsor.  They've placed some portion of the success of their career on the project that is winding it's way through the organization.  If they weren't passionate about the results of the project they would not have lobbied to make it happen.  As the Project Manager, you may not fully understand the full reasoning of why it is important to the Project Sponsor - but trust me, it is.  As the Project Manager, it's your job to keep this individual fully informed of  what is happening within the overall project.  That's not saying you have to update them on every decision, every risk that gets identified or small shifts in resources.  That's what they expect you, as Project Manager, to do - it's your job!  What they do want to be made aware of are the big things - and each sponsor will have their own definition of what the "big thing" is.  Most times you can focus on the following:

1. Identifying others in the organization that are attempting to change the approved scope of the project - thereby causing ripples throughout the project that will potentially change the product that is delivered or impact the budget, timeline or resources involved in the project.
2. Identifying when 3rd parties are not meeting the expectations identified at the beginning of the project or as documented when the contracts were signed and they engaged on the project.  And expectations means that they are either performing or not performing in a way that could impact the quality of the delivery, the budget, timeline or resources involved in the project.
3. Identifying items that surface throughout the project that insert risk in to the overall activity and could cause the project to derail and go over-budget, increase the time necessary to deliver the product or alter the number of resources needed to complete the identified activity and tasks associated with the project.  It's the Project Managers job to mitigate risk - and the Project Sponsor will expect that activity to be done, however, they will want to know when these risks or issues are identified and what the team is doing to resolve the risk.
4. Identifying when production issues or shifting priorities impact the overall project.  These are issues outside the control of the Project Manager, but the Project Manager better be communicating these up and across the organization.
5. Identifying what issues need to be escalated and then managing those items so that they do not impede the progress of the project team.

The Project Manager should meet with the Project Sponsor early in the overall project to establish the ground rules.  What are the specific items that the Project Sponsor is worried about?  What does the Project Sponsor want to see in project updates?  How does the Project Sponsor want issues escalated?  How often does the Project Sponsor want to be updated on the overall progress?  How does the Project Sponsor want to see items that need to be escalated?  As issues arise in the project - what are the give points?  Is there a commitment date where the product must be delivered by a specific date and that means more resources need to be pulled in when needed?

The difference between a good Project Manager and a great Project Manager is the ability to understand that it's not just managing activity within the Project Team - but managing across and up through the organization to ensure that the project can stay on track and be a success.

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

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

Being a Project Manager

Over the years, I've had many people ask me about being a Project Manager.  What are they?  What do they do?  Would I be any good as a Project Manager.

So, with those questions in mind, I though I'd take some time and write up my thoughts on being a Project Manager.  Hopefully, this will help some of those individuals that have in one way or another kind of stumbled in to the role and maybe help someone who is trying to figure out if being a Project Manager is the next right move in their career.

So, what do Project Managers do and why are they needed across most organizations and professions?  The simplest definition is that the Project Manager has the overall responsibility and accountability for the successful planning and execution of a project.  The title has been formalized across a broad range of professions including, but not limited to, architecture, construction and information technology.  For the purposes of this posting, we'll stick to the role that the Project Manager plays within Information Technology projects.

So, the Project Manager, in short, is supposed to make stuff happen.  And now for the tough part, they are supposed to make stuff happen, while limiting risk to the overall organization, ensuring that costs stay in-line with initial projections and limiting conflict between individual resources/teams involved in the project.  Here are some of the items that a good project manager makes happen:

• Planning - identify the sequence of events/tasks needed to complete the project.
• Resourcing - ensuring that the right resources are available at the right time to handle work activity within the project.
• Budget Development - identifying the various budgets and successfully managing them to ensure no cost overruns.
• Quality -  ensuring that quality is accounted for throughout the entire lifecycle.
• Risk/Issue Management - through work with the Project Team, early identification of items that could impact the timeline, costs or resources associated with a project and creating and executing mitigation plans to reduce or eliminate the risk.
• Documentation Oversight - oversight of the artifacts to ensure that those artifacts needed within the overall project lifecycle are created and maintained.
• Team Leadership - act as an escalation point for the team and actively work to remove roadblocks.

To perform the role successfully, a good Project Manager will understand how to ask penetrating questions - uncovering the little things that are hiding in the project that could possibly derail the efforts of the team.  They will actively manage activity to uncover undocumented assumptions that mean the difference between success and failure of the overall project.  Additionally, they will work aggressively to eliminate conflict at a personal level or between various teams to ensure the smooth sharing of information that increases the potential for project success.  The Project Manager understands that their primary role is to identify and eliminate risk at every step within the overall project plan. 

Managing Interruptions 

On a day to day basis, the Project Manager looks to minimize interruptions to the activity planned within the project schedule.  The building of complex systems requires focus and attention.  Each interruption is a cost to the task underway - studies have proven that an unplanned interruption in the concentration of a developer can mean 15-20 minutes of lost time as the team member refocuses back to the work task.  Just five interruptions a day means one lost hour of productivity - or a loss of 5 hours for the week.

In most instances, these interruptions focus on the most senior members of the team.  They typically have been with the organization the longest and have the most knowledge of the inner workings of the systems in production.  Additionally, they are probably the team members that have been involved in the overall planning/design work for the activities underway.  People naturally gravitate to them to resolve issues or to  understand what it is that they are supposed to be doing.  A Project Manager understands the natural conflict in the responsibilities of these resources.  They need to find ways to give these resources uninterrupted time in their day to handle the tasks that they've been assigned, they also need to find windows of planned time where team members know they can approach these individuals and resolve outstanding questions or get help on production related problems.

Removing Roadblocks 

One of the most significant roles that a Project Manager can play for the project team is to clear the road ahead of the team - removing the obstacles that continually pop-up and want to derail the team.  Project Managers tackle the politics at play within an organization and make sure that they don't touch the team - allowing the team to focus on the work.  They identify issues early and then work with leaders across the organization to remove those issues before it impacts the ability of the team to move forward.  If there are open decisions, they will manage activity to ensure that decisions are made.  If there are contracts to be completed before an outside resource is made available, they will find the necessary people and get the contract approved.

Prioritization

Some people don't understand how to prioritize work.  A good Project Manager will stay abreast of what their team members are working on.  They will walk about the office checking in on team members, or if they are remote spend time on the phone talking with the team member.  Yes, some of this will be related to the assigned project activity, but they will also steer the conversation to find out what else might be on the plate of the team member.  They then actively engage in making sure that the project activity is getting the priority it deserves.  Sometimes this will be in 1-on-1 conversations with the team member, and sometimes the Project Manager will escalate the issue to make sure that team members can maintain the right focus on their work activity.

Project Managers are essential to the successful completion of projects.  They work the issues, they manage conflict and they keep the companies management team aware of the current status - that means they are regularly informing the Project Management Office of the work efforts and whether they are on track to meet specific milestones related to cost, timelines and resourcing.

How do you use Project Managers within your organization and within the overall SDLC process?

Blog Tags: SDLC, Project Management, Project, Management, Manager, Project Manager

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

Capturing and Using Milestones - Managing the Plan and the Portfolio

So, the last time we chatted I discussed the importance of milestones.  With this posting, I'd like to run through the milestones that I use, explain why I think there important and discuss how I'm beginning to use them within the overall lifecycle.  For purposes of this discussion, I'm focused on the resources and time components of the project.  We can discuss the "real dollar" budget vs actual in a later posting.

Let's get started and dive right in to the discussion. 

As I've discussed in previous postings, my teams use MS-Project to plan and track our project activity.  Each project is assigned a unique project number and name.  The project number is used to assist in standardizing many of the project artifacts that get created throughout the lifecycle.  The unique project number is used on op level artifacts that define the requirements and technical specifications all the way down to defects logged so that we can tie all activity with a project back together.

The Project Manager has the responsibility to create the project file.  They use a standard template that has been updated and modified over the last four to five years. 

• NOTE: This is important once you create our template (or any other project artifact) don't let it sit and collect dust.  Occasionally, you need to go in and dust off the artifact, in this case the project template, and see if everything still makes sense.
  
  • Do you need to add or remove default tasks?
  • Do you need to reassign default resources?
  • Does it make sense to update the time frames (start and finish dates) associated with default tasks?
  • Do you need to restructure the predecessors?

The template has sets of default tasks and milestones that we have defined for each of the six phases of the lifecycle that we utilize.  These tasks and milestones identify standard activity that normally occurs across the various teams involved within the lifecycle.  Some of these tasks are business functions, some of the tasks are technical functions.  So, from a management standpoint, I'm interested in several things:

1. What are the stop and finish dates for each of the identified phases within our lifecycle?
2. What is the point where we have enough knowledge where we can identify a target delivery date with a high degree of confidence?
3. Is activity on track to hit the identified target dates?
4. Are we on track to hit the baseline targets - or does the project file indicate that we will miss the milestone dates?
5. How do the start and finish dates within a given phase track against the overall projections used in portfolio management?
6. Are the resources projected within the portfolio accurate against what is being tracked in the actual project?

Within each of the six phases of our lifecycle, I want to know the start and finish dates of specific activities - these are my milestone dates.  So, automatically, across our six phases, I'm keying on the start date of the given phase and then a milestone towards the end of the phase that signifies that we consider activity within the phase complete.  Sometimes, there is trailing activity following the "finish" milestone.  That's why I can't necessarily rely on the finish date shown in the summary task.  For most organizations, you can probably get away with relying on your start and finish dates within the summary task - however, there will be some organizations that are like mine where there is some miscellaneous activity that goes on that you don't necessarily want to recognize as holding up the next phase of activity.

Next, we need to know when we are going to deliver the product in to production.  We can do all the planning and building that we want.  But the Marketing and Sales folks generally want to know when it's going to be available.  In many cases, they have marketing plans and communication strategies triggered by the implementation date.  Within our lifecycle, we have a standard milestone triggered at the completion of our Detail Design activity.  This is when we place a stake in the ground and commit to a delivery date.  (Side note, as with all things in life, sometimes we end up missing the date, but this is our internal commitment.)  Once the Detail Design is done, we create our final baseline (notice I said final baseline).  Once the final baseline is in place - that is what is used to create final stats at the end of the project.

Here is where it get's interesting.  On a daily basis, we have created a program that goes in and extracts these milestone dates from all active projects.  As well as collecting the milestone dates, the routine also captures the identity of all resources involved in each of the six phases of our lifecycle.  (This routine will be expanded to also capture the baseline dates stored within the project file.  No, I haven't perfected the whole thing yet.  We still continue to iterate through this and mature our lifecycle and metrics.)  This routine, also goes in to the Master Portfolio and extracts the estimated start and finish dates for each phase of our lifecycle as well as the resource projections.  All of this information is extracted and placed in a data mart.

So, at this point, I've extracted and recorded in the data mart, the estimated start and finish dates based on our Master Portfolio, the actual start and finish dates according to the Project Plan, the final baseline start and finish dates and the milestone activity identifying completion of our Detail Design where we establish our final baseline.   On top of all this, I have the projected resource allocations through each phase as well as the actual resource allocations recorded in the Project Plan.

On top of the data mart, we have created a web site that allows us to drill in to any given project: active, on-hold or waiting to be initiated.  The web site allows us to compare the actual plan against the overall portfolio projections both from a timeline perspective and a resource perspective.  As a manager, I can begin to answer the questions from above.  I can compare actual the start and finish dates of each phase of the lifecycle to the baseline dates as well as the portfolio dates to see if something has changed and if we need to make adjustments.  I can tell if our initial estimates are off and whether additional resources have been assigned to a given phase of the project.  I can tell when something has slipped that will impact our overall delivery date.  I can mange to the exceptions and initiate conversations with the Project Manager when I see something slip or when a date suddenly moves up in the schedule.

This is what works for my organization and what has allowed us to significantly increase the number of projects moving through our pipeline and increase the pace of activity.  We are by no means finished, we continue to tweak our lifecycle and the way that we are managing our projects.  But, based on the statistics drawn from these metrics, we have made a difference in the way projects are managed within the organization.

Speak up! What milestones are you using and more importantly how are you using them within the projects you manage?

Tags: SDLC, Project Management, Timeline, Tasks, Milestones, Budget, Template, Management, Projects, Software Development, Applications Development

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