"The five basic steps you must do on a project" - Part 6

step 1 - Carefully define the outcome from the project.

step 2 - Defining and documenting requirements

step 3 - Creating a "doable" plan

step 4 - Manage Risks and Issues

step 5 - Track, Validate,  and Update

Over the past 5 weeks I have shared with you the five basic steps for managing a project. In this final part of the series, we will look at one very critical item that occurs throughout a project, Communication. All to often I have been asked to assess the health of a project and found that it was in trouble. Very often, communication issues were one of the root causes.

Communication is a core discipline of project management. From communicating status and schedule to escalating issues, you must be able to communicate well. More importantly you must communicate frequently and consistently. If you need a vendor to deliver your new commercial pizza oven before the shelving vendor installs the stainless steel storage racks, make sure that you communicate that to both vendors and your team. This way when the shelving shows up early and you are not there, somebody can tell them to wait or contact you directly. If you are keeping the project tasks on a checklist, send copies out to all of the team and vendors on a regular basis. One vendor may see where something is ahead of schedule and call you and say that they can also do their tasks earlier. This can save you time and money. Kind of  like that huh?

 One last point, if you communicate by e-mail, make sure you follow up with a phone call on critical items to make sure the recipient not only got the e-mail but understood it. Double checking once in a while is one of the best communication tools I know.

The following is a compilation of a series of tweets I did the week before Christmas and things you can do to get ready for a project that will start right after the holidays.

Yep, Xmas is this Sat. and people are taking off. During the holidays it is difficult to get a lot done with many people away so the goal is to get things lined up for a quick start in Jan.

• The first step is to set some mini milestones for the first two weeks after the holidays. Set dates for tasks such as the first draft plan.
• Review the project charter and make notes on it such as what scope items need more definition or which appear to be difficult.
• If you will need to meet with key SMEs or sponsors in early January try to schedule the meetings now so people know what to expect.
• Put together a list of people that will need to be interviewed or involved in the requirements phase.
• Another thing to do to be ready to start the project is put together a 2 week task plan so that you know what needs to get going right away
• If possible, go ahead and set up the project repository for documents now. This way it is out of the way and ready.
• Before everybody leaves schedule the project kickoff meeting and first two team meetings. This lets others plan their first 2 weeks also.
• Get the templates for the risk plan, issues log, communications plan etc into the repository and set up for the project.
• Look at the project charter and start to determine what resource roles you will need. This gives you a starting point when you return.
 

By doing the above before you take off for a well deserved holiday break you are giving yourself the peace of mind of knowing what you have to do when you get back. Enjoy!

Thanks for following me. I want to wish all of you a happy holiday season and very prosperous new year.

"Yes Virginia, even Santa has a project plan"

I was getting ready to leave for the day when I saw one of the PMs, Virginia getting ready to leave. I asked if her project plan was ready for review. She looked at me and replied, "I don't need a plan".

Obviously this was not the answer I wanted. But before I told her she had to do one I decided to play along a bit and asked some questions. "Okay, so what happens if the vendor is late with the software?" "How are you going to test the solution?" "What types of communication have to be done?"

Virginia stared at me and said "The team will figure it out as we go.  If everything goes right we shouldn't have any issues."

I then asked, "But what if everything doesn't go right?. How will you handle those unexpected items?"

Virginia snapped back, "If they are unexpected, we can't plan for them anyway. For Pete's sake Terry it's not like Santa Claus has a plan."

"Virginia", I said, " I can guarantee you that Santa has a superb project plan."

Virginia rolled her eyes and scoffed, "No way!"

My reply was simple. "Yes  Virginia, Santa has a project plan. To prove it, consider the following:" 

 "Santa has a project plan that details all of the steps needed to get ready for Christmas. It covers the number of toys he needs, getting the sleigh set up, setting up his route for the night, notifying the various countries of his flight path,  and where he will take rest stops. Have you ever seen Reindeer droppings on a roof? Of course not because he plans where to stop."

"Santa has a project schedule. It sets out when the toys will be done, what time he wants to take off, what time he arrives in each country, and what time he will return to the North Pole."

 "Santa has a resource plan. How else can you control hundreds of elves without roles and responsibilities defined?"

 "Santa has a communications plan. The naughty and nice list tells him information he needs. The FAA and local authorities know when he is coming through their area."

"Santa has a contingency plan. He has alternate plans and routes to deal with last minute changes, bad weather, broken sleigh runners etc."

Virginia stared at me in disbelief.

"But Virginia, he has to have a plan. He does his work in one night and has never missed a Christmas. Can you tell me that you always deliver on time and have never had a failed project?"

 Virginia answered. "No unfortunately I have had a failed project and yes sometimes I miss schedules." With that answer all Virginia could say now was, "Is it ok if I give you the plan Tuesday?"

And I replied, "It is Christmas, you can have till Wednesday."

Happy Holidays!

"The five basic steps you must do on a project" - Part 5

step 1 - Carefully define the outcome from the project.

step 2 - Defining and documenting requirements

step 3 - Creating a "doable" plan

step 4 - Manage Risks and Issues

step 5 - Track, Validate,  and Update

This is where the Management in project management occurs.  Throughout the project, you need to track the tasks, validate that they are being done, and update the plan and schedule as changes occur. Don't just rely on verbal updates from employees and vendors. Whenever possible, visually check status of major tasks. Either go to the location where the work is being done or ask for visual feedback. For example in a building move, request copies of subcontractor receipts, delivery invoices, and digital photographs. On a marketing project, ask for proofs to review especially if the vendor says that they aren't ready or happy with it yet. These mid-course reviews can actually help you solve potential issues early.

As tasks are completed, check them off of the plan and schedule. If rework is needed then update the plan with the rework tasks. For example a vendor delivered new desks for a new office but they were missing the locks. The vendor said they would install them next week. Add that task and track it. If tasks are ahead or behind schedule update the schedule and share that with everybody so others can make changes to their schedule as needed. If the plumbers were scheduled for Monday but the rough in carpentry work was not ready, you want to let the plumber know so you aren't stuck with paying for the plumber to sit there.

This is another compilation of my tweets that look at how to put a project on hold for the holidays and how to build a restart plan.

During the holidays projects that are underway may be put on hold due to people taking time off. This can be good if you plan for it

• The first step is to identify tasks that must be done before the project goes into holiday mode.
• Once the tasks that must get done are known then you can set the date that the project will go into hold mode. This gives you a target date
• The next thing to do is meet with the project team to make sure there are no open risks or issues that must be addressed before the holidays
• The next task is to build a restart plan for the project. Don't assume that you can just jump in and pick up where you left off.
• The start up plan needs to take into account which tasks need to be restarted first and when the needed team members are back at work.
• When you create the restart plan add a task for a restart meeting with the team and a plan review to make sure something hasn't changed.
• The project restart plan should cover the first 2-3 weeks of the project after the holidays and designed to dovetail into the project plan
• During the first week of the restart plan make sure that people aren't over utilized. There could be other items that will take there time.

Once the restart plan is done communicate it to the team and get feedback and buy in. This will help ensure a successful restart

 

"The five basic steps you must do on a project" - Part 4

step 1 - Carefully define the outcome from the project.

step 2 - Defining and documenting requirements

step 3 - Creating a "doable" plan

step 4 - Manage Risks and Issues

Any project, regardless of size will have risks and issues. Risks are items that could occur and issues are items that have occurred. Knowing up front the potential issues , risks, helps you be prepared for dealing with them if and when they occur. 

 When you are planning the project you need to identify the "bad" things that could happen to your project and determine how likely they are to occur. For those that have a higher likelihood, determine what actions could be taken to prevent the risk or what actions could be taken to mitigate the risk if it happens, i.e. becomes an issue.

Let's look at an example. Let's say you have a small independent insurance brokerage and you are upgrading your office computer system with new servers and network components. The old server is on lease and the new equipment will be on a new lease with a new vendor. A risk might be that the new vendor fails to deliver the new hardware on time. Your contingencies could be:1) Arrange an extension of your lease with the old vendor 2) Have the new vendor host your applications offsite temporarily. By identifying these actions up front you can ask both vendors what it would cost and what actions would be needed to execute the contingency plan. By doing this you have a plan ready to go so if the risk becomes an issue, you don't have to scramble.

The following is a compilation of a series of tweets I did on keeping a project moving forward during the holiday period when a lot of team members may be away.

It's Holiday time. Do you have an active project & are prepared to keep it going during the holidays? Here are some tips on keeping the project moving forward.

• The first thing to do to plan for the holidays is to get everybody's schedule. Include the project team, SMEs, sponsors, and support staff.
• The next step in planning for the holidays is to create a punch list of everything that needs to be covered or done between now and mid Jan.
• When putting together the punch list include project tsaks from the plan, issue resolution, hardware and software purchases etc.
• When putting together the punch list only include those items that must be done. Anything that can wait till after Jan 15th can be omitted.
• Now that you have everybody's schedule and the punch list you can start assigning people to cover the tasks based on availability & role.
• Some special assignments to look at are who to escalate critical issues to if the sponsor or senior management is out? Designate this role!
• If you as the PM are going to be off who is covering for you? Desiginate somebody and communicate that to everybody.
• Once the punch list and schedule are done get everybody together to review and make any changes. The more you communicate the better

Make sure to thank everybody who is covering tasks and working during this period. Let them know you appreciate their efforts!

Here are some some tips on pushing your project over the finish line to meet end of year deadlines.

The first step in the big push is to do a project self assessment to determine eexactly where the project is and what is left.

Once you know exactly what is left to do go through each deliverable and task and eliminate any that are not absolutely needed.

Now that you have the list of tasks that must be done, re-estimate the work and duration for each task

Using the new estimates build the critical path plan first to determine how long that will take.

If the critical path items will finish before the end of the year then you are probably ok. Go ahead and complete the plan.

If the critical path takes longer than the end of the year the next step is to identify those tasks that are causing the schedule to stretch

Once the tasks that are causing teh schedule to stretch are identified, the next step is to figure out how to shorten the these tasks

 

There are 3 ways to shorten time on these tasks 1) reduce complexity 2) assign to senior resources 3) assign to multiple resources

Once the tasks have been addressed complete the plan and review with team and sponsors

Now that you have a plan you can start identifying risks and contigencies for the plan. Focus on risks to schedule and quality.

If delivering the project requires overtime and / or weekends you need to communicate that and get buy in from the company and the team

"The five basic steps you must do on a project" - Part 3

step 1 - Carefully define the outcome from the project.

step 2 - Defining and documenting requirements

step 3 - Creating a "doable" plan

Planning is an essential part of all project work. It is also more than a schedule or list of tasks. Planning needs to include the schedule, risk management, communication plans, contingency planning and other items depending on project size. There are many sources of information on how to create a plan including PMI. The important thing is that no matter what the size of the project, take the time to plan it out.

Project plans do not have to be onerous and if done right can help you achieve your project goals. At the minimum you should determine and document the following:

·Major deliverables
·Tasks needed to complete deliverables
·How long tasks should take
·Which tasks are linked or dependant on other tasks
·Who is doing which task
·What risks you need to watch out for
·Who do you need to communicate to and what do you communicate

Once you have documented the plan, make sure everybody has a copy. Review it daily and check off items as they occur or are completed. Don't worry if the plan changes, that is normal. Just document the change and make sure you know what else can be impacted by the change

"The five basic steps you must do on a project" - Part 2

Last tip I covered step 1 - Carefully define the outcome from the project. This time we will look at step 2 - Defining and documenting requirements

The subject of requirements is one of the most discussed items in all of project management. It is also one of of the major causes of project failure. Even on small projects you must elicit the requirements to the point that they can be written down and well understood by everybody involved. There are three generic classes of requirements:

· Functional - This is what the application or final outcome must be able to do. Examples include: The new building must have a ladies' and men's washroom. The web page must allow viewers to submit questions via e-mail.

· Technical  - These are specific requirements that support functional requirements. For example, the webpage must be available to receive on-line orders 24 hours a day or the building must have a 240V service for the air compressor for the shop.

·Time Oriented - These define when key events must occur such as when the new restaurant must be ready to receive food shipments or when the webpage must be ready to handle orders.

The important point is that these requirements must be documented and validated with everybody involved. Technical requirements must be validated with the technical experts.

If you do not write the requirements down you run risk of doing too much work, delivering the wrong items, or missing a critical component. All of which will cost  you time, money, and angst. On small projects requirements can be jotted down on a punch list or written on a white board (Just don't erase it)   for all to see. On larger projects you will want to use a more formal method. Next week we will talk about plans and planning.

"Use checks and balances to manage project risks and issues."

Risk and issue management is by far one of the most important tasks for a project manager. Managing the risks and issues well is a critical success factor in delivering a successful project. To better manage the risks and issues, try setting up a process that employs checks and balances to manage the risk register and issue log. Assign different project team members to "own" the risk register and issue  issue log. This way, you as the Project Manager can utilize these tools outside the duties of maintaining them.  Thus you can look at them fresh each time you review them. Make sure the other team members are also reviewing these regularly and bring up concerns at project meetings

"The five basic steps you must do on a project" - Part 1

Most of our work is in the IT project space. But we all know that projects are performed in almost every business, even small businesses. Take for example a retail store that is relocating to a new space. That move fits the classical definition of a project. In smaller companies, these projects are done by the business owner or whoever might be available. So starting this week, I am going to introduce the five basic things you can do to ensure your project gets done the way you need it to. These tips apply to practically all projects. They are geared to the very basics that ensure success.

Step 1. - Carefully define the outcome from the project. Saying that we need to move to the new building is not enough. You need to determine exactly what the final output or result is. This will form a target that you can continually judge progress against to make sure you are on track. The outcome is your final result and should not be confused with requirements. I'll discuss those next week. An example of an outcome statement could be, " We need to move the entire store to the new Pottsylvania building by May 20th to be ready for the start of tourist season and because our current lease expires on May 31st." This statement establishes the what must happen, the why, and the bad thing that occurs if you miss the date. This helps focus the project on accomplishing those tasks that contribute to the goal and help avoids doing tasks that don't. This may seem too basic but it is a step I have seen skipped on both small and large projects with very disastrous results.

When you do create the outcome statement, I suggest that you write it down and give it to all of the people involved in your project, even vendors. If appropriate, a large poster with the outcome printed on it makes a good visual reminder to everybody involved.

 

A portfolio health analysis (health check) looks at all of the projects in the portfolio to ascertain if they will meet the goals the company established. Using the data gathered from the steps the company can now make adjustments to the portfolio as needed. The portfolio health analysis can be conducted at anytime but should be done at least two times a year. The portfolio analysis needs to look at six factors: Budget, schedule, resources, scope, priority, and strategic fit.

 

The health chack consists of six steps as follows:

 

1) Look at the projects underway, waiting to start, and completed vs what was planned

2) Look at the budget to date vs planned and actual spend to see if the entire

portfolio can be completed within budget

3) Determine if the resource utilization vs. forecast indicates a shortage of resources.

4) Check each project vs proposed scope to ensure there are no significant unapproved changes

5) Make sure that projects are being executed in accordance with the priorities

6) Check that projects aligned with the company strategy are still in alignment

Using the data gathered from the steps the company can now make adjustments to the portfolio as needed

Check out this week's tip on being prepared to handle project portfolio changes at http://bit.ly/c4nANt

Check out this week's tip on using an objective method to select and prioritize projects for the portfolio at http://bit.ly/c4nANt

Happy Halloween everybody. Check out this week's tip on portfolio prioritization, the Headless PM at http://bit.ly/ciyf0W

We are well into 4th quarter. Now is the time to do a sanity check on next year's projects. Is your organization doing the right projects at the right time? If you don't know a portfolio review from Project Right Track can answer that for you. Check us out at www.projectrighttrack.com

The Project That Wouldn't Die

I was working late one evening trying to finish a project plan. It was raining outside and the emptiness of the office was only interrupted by the sound of thunder and flash of lightning. Then "He" appeared in a black robe and sickle in hand , worse than death, it was the Grimm Sponsor. He spoke in a British accent, "Terry", he said, I need you to take over the ghost website project. "NO!!" I screamed , "That project has been going on forever".

The Grimm Sponsor replied, "Sorry Terry  but the Project Manager disappeared and we need you to finish the project".

"What do you mean disappeared? I asked."

"Never mind that", said the Grimm Sponsor. " The project documents are downstairs in the project war room". "Go take a look and let me know that you can finish this before Thanksgiving".

So with great dread and trepidation I headed downstairs. With each step I could hear the stairs creek, "Scope Creep, Scope Creep, Scope Creep" they groaned. When I reached the bottom I started walking down the hallway toward the door. As I passed several closed doors I though I heard a voice. "More time, more resources, more money" said the voice. As I kept walking, the air got colder. All of the sudden I tripped over something. I looked down and to my horror it was a skeleton. In its curled hand was a document. I picked it up and to my amazement it was the project charter. On it the version number was faded but looking closely it was version 1.0. I opened the document and took a look.

"Wow, this scope doesn't look that bad. I wondered what happened?" I asked. Then the voice came back. "More time, more resources, more money it growled" louder than before. Once more and even louder came the voice. "More, More, More!!

I came upon the door of the war room. I started to grab the handle. It was cold and forbidding to the touch. The voice came again, shouting " More, More, More". Slowly I opened the door. And there it was , in the middle of the room. Screaming "More, More, More" was that most hideous of creatures. The great Scope Blob. Oozing red ink it looked like it was growing.

Then it started heading towards me. I rushed for the door. It was jammed! "Oh No!" I was going to be scoped blobbed to death! Then the lights went out. A flash of lightning lit up the room. in the corner was a table with an old moldy pizza. Next to it was a a knife. I ran over and grabbed it. I lunged at the scope blob and cut away. A requirement here, gold plating there. I slashed and cut with all of my might. The blob wailed and whimpered. Then the lights flickered on. Where the large dreaded blob was before there were now several smaller blobs. I picked up each one and put them on the table. I then put them in order by size.

Just at that moment in came the Grimm Sponsor. "Sir", I said, "Pick the ones you need first and that will be delivery one". Then we will  deliver the next few. " Jolly good" he bellowed. " You have certainly cut this project down to size"

So the next time you're face with that project that just seems to grow, remember to split it up in manageable chunks and attack one at a time. Happy Halloween!

Check out this week's tip on the PRT web site at http://bit.ly/c4nANt. This week is part one of our halloween version, the Headless PM. Enjoy!

10 reasons why mid size companies need to have a project management office or PMO.

#10 - Mid size companies must keep tight control of budgets. A PMO can help by tracking project spend and working with mgmt to manage costs.

#9 - PMOs can help business teams in preparing project propsals and charters. This helps foster a consistent method in the organization.

#8 - PMOs can help companies look at new ways of executing projects inculding using agile methods.

#7 - PMOs can help companies implement project governance such as project reviews and steering committees

#6 - As companies undertake more projects there will be more dependencies between projects. The PMO can identify and manage dependencies.

#5 - As companies grow a consistent way of managing projects becomes important. The PMO can set project management standards and processes.

#4 - As companies grow the executives will need info on projects to make decisions with. The PMO is responsible for providing this info.

#3 - Mid size compaines face an ever changing business climate. The PMO can help with managing changes to the project portfolio.

#2 - Mid size companies may face resource utilization challenges. A PMO can help forecast and track resource utilization on projects.

#1 - As companies grow, the number and size of projects increases. A PMO can coordinate selection to make sure the right projects get done.

Here are 10 project management quick tips that I use on my projects.

#1 - At the end or beginning of each week take a look at the tasks for the next two weeks and verify their start, duration, and dependencies

#2 - Confirm with each owner with tasks due in next two weeks that they are on track and what they need from you and others to stay on track

#3 - Review risk list every week to determine if a risk is likely to be triggered. This way you can prep the mitigation steps just in case.

#4 - Regularly check status of other projects that can impact your resources or tasks so that you can invoke contigency plans if needed.

#5 - Read the last 2 weeks status reports to remind yourself of old issues or actions that have not been addressed.

#6 - Conduct a weekly checkpoint call or meeting with vendors to make sure they are on track and what they need from your team.

#7 - Use punch lists to list tasks needed to be completed when milestones are coming due. This helps you not miss anything.

#8 - Have regular reviews with stakeholders and sponsor. Use the time to resolve issues and show them progress to date.

#9 - Use flow charts or process diagrams to describe functionality on key functions. Pictures are your best friend!

#10 - At the end of the week jot down the three key things accomplished and the top issue of the week. These help you plan for next week.

Tools for a virtual team

According to Forrester’s US Telecommuting forecast an additional 29 million telecommuters will enter the remote workforce by 2016, totaling 43% of US workers. Technology has evolved so quickly that the tools we use as remote workers are the same tools we use at the office. It is estimated that 60% of office based employees use virtual teaming technologies daily. Here are some of the tools you can use when managing remote project teams.

The 1st tool required for virtual teams is a central calendar for all team members to post vacations, milestone, schedule meetings etc. When using a central calendar establish some basic standards on nomecalture, language etc so everybody can use it effectively.

Another valuable tool for virtual teams is a common project document repository such as sharepoint or dropbox. Use a check in and check out model for the document repository to prevent accidental overwrites and notify others when a document changes.

Video conferencing is another effective tool for virtual teams. It helps to build better interactions among the team. You don't always need high end video conferencing tools for things like one on one meetings. If your company allows consider Skype or OOVOO.

Another useful tool for virtual teams is web based conferecing such as Go To Meeting or WebEx. Make sure to establish rules for the use of web based conference tools as well as standards for how to conduct a virtual meeting.

When managing a virtual team consider using a project management and colaboration tool. This helps with task assignment and tracking.When using a project management tool make sure to enable the email function so as to notify team members when a task is assigned to them.

Reply allFavoriteSend to Email

Tools to support virtual project teams

The virtual workforce is growing. Currently 25% of US workers work remotely at least part time. This is going to increase in the next few years to almost 43% according to Forrester Research. Thus the chances will increase that you will have to manage a virtual project team. There are many tools that help support a virtual team. One of the easiest to implement but also one of the most important is a central calendar for the team. The calendar should be editable by all team members and should be used to:

• Request and schedule meetings
• Show holidays and vacations
• Show major milestones

Most companies will have a calendar as part of their email or collaboration software. If you don't have access to one, tools such as Google Calendar work well.

Project Management Tip of the Week

Check out this week's tip on the PRT web site, http://bit.ly/c4nANt, on team building on a virtual project team.

"Right size your project documentation to fit your project."

Project Management methodologies were created to promote consistency, quality, and completeness in the execution and documentation of the project. Project documentation should support the execution of the project. Many times, the methodology may call for a document or a format that may not be useful for your particular project. When that occurs, document why the document was skipped or changed and move on. Only create that which helps you manage the project.

Project Communications Plans

On large projects particularly you should create a formal communications plan. The plan should define how and what communications will be used throughout the project. Areas to cover include:

• Status reporting and team meetings
• Project steering committees
• Sponsor meetings
• Escalation
• Vendor communication
• User communication
• External communications
• Project document repository
• Risk and issue submissions

On smaller projects you can include the communications as an addendum to the charter

Top 10 Project Portfolio Managment Mistakes

Here are numbers 5 through 1 of the top 10 PPM mistakes organizations make.

PPM mistake #5 - Overlooking true business value. Most companies measure value as ROI or another financial metric thus missing other value. Project value is also the utility that is delivered to the company. Identify and track that with the portfolio. An example of utility is delivering ability to sell a new product online. There is ROI but also a new use to the company.

PPM mistake #4 - Not realigning the portfolio. As time progresses the portfolio can change. What was low priority in Dec may be high in May. I recommend to clients a quarterly portfolio review to check portfolio & make adjustments. This is also a good time to add new projects.

 

PPM mistake #3 - not balancing the portfolio. Companies and departments can absorb only so much change or new things. The portfolio should be balanced between # of lg, med. sm. projects., # projects per dept., # projects that impact a customer group etc.

 

PPM mistake #2 - using H, M,L to prioritize projects. Using this method causes deartments to make all of their work high priority. If project priority is only H, M, L senior management will not know what projects are really most important. Use a numerical scale  starting with 1 for highest priority, 2 for next highest and so. This gives senior mgmt the tools they need to make portfolio decisions

PPM mistake #1 - Not cancelling projects. Companies tend to let projects have a life of their own. Once approved a project must be done. During the portfolio review look at projects not started and reaffirm their need. If the need is no longer there, cancel the projectCompanies should also consider canceling projects when ROI will not be realized or if project has been waiting to start for more than 12 mo.

Top 10 mistakes made in Project Portfolio Management (PPM)

The following are numbers 10 - 6 of the top ten mistakes I have seen organizations make with their PPM process implementation. Next blog will have #5 - 1

PPM mistake #10 - only including new, major initiatves in the portfolio. This hides the impact on resources and budget from other projects.

PPM mistake #9 - No risk / reward view of projects. Complex projects should be included in the protfolio if ROI or business value is high

PPM mistake #8 - Not sequencing the start of projects. Allows too many projects in play at once which can drag on the portfolio. Projects should be started based on priority, complexity, and due date. Delaying a project start can help other projects get done.

PPM mistake #7 - No tangible IT investment strategy. IT Projects are done for the business but they are also an investment.When a company invests in an IT project it should be done as part of a longer term strategy. This way the money spent contributes to growth.

PPM mistake #6 - Not monitoring portfolio health. We measure project health to know if it is on track so we should do the same for portfolio. Measure portfolio health by number of projects approved, budgeted, started, on schedule, off schedule, completed, & actual spend vs. planned.

Project Right Track Introduces new Virtual PMO solution

Project Right Track has developed the Express Track Virtual PMO Solution to provide an affordable, scalable, and effective portfolio management solution for smaller companies. Express Track provides a skilled PMO team on a part time basis. Throughout the budget year the team works to provide the structure of a PMO including:

• Coordinating project identification and selection Prioritization and scheduling of projects
• Monthly Review meetings
• Quarterly on site portfolio reviews
• Portfolio Financial Analysis

Using the Express Track service results in the more efficient management and delivery of projects that are aligned with the organization's strategy. Better project tracking and value realization means fewer surprises.

Estimates and Requirements

This week the tip of the week at http://bit.ly/ciyf0W is about being prepared for the expected and unexpected issues that can impact the project. One of these expected issues is a missed requirement. This happens frequently on IT projects. Software applications can be fairly complex so it is likely one or more requirements may be missed in the original requirements gathering phase. What generally happens with these is that the requirement is added and the project schedule and budget are impacted. A better way to handle this is if you are prepared for it. After the initial requirements are done go back to the estimate and assign a value to each requirement. This serves two purposes. First it gives you a tool to validate and refine the estimates. Second it now gives you a tool for the case of adding a missed requirement. When the requirement is identified estimate what it costs. Now you can go back and see what the real impact to the budget and schedule is. Then the decision could be what requirements can be dropped to account for the new one or maybe the new one can fit into the contingency funds.

An estimating we will go

Restarting the blog this week by looking at project estimating and scheduling.

Check out the PRT web site at http://bit.ly/ciyf0W  to read the tip of the week on the importance of continually reviewing and revising the estimates as the project progresses.

Agile Methods

Is your company ready to use an agile method for their IT projects? Check out the blog this week for discussions on this subject. The tip of the week on our web site discusses what projects make good first projects for an agile approach. Read the tip at http://bit.ly/ciyf0W

Escape Velocity

When an IT project has been delivered sometimes the hardest thing to do is to get out. There usually are post go live defects and issues to deal with. To make sure that you can turn over the delivered application and close out the project you should develop a transition plan prior to go live. This plan should detail how long the warranty period is, who takes over support, what documentation is needed fore turnover etc. Having this plan will help you achieve escape velocity.

1,2,3,4 what are we counting for

This week the tip of the week on the Project Right Track web site, http://projectrighttrack.com/support.html discusses defect rating and prioritization for IT projects. My premise is that we spend too much time worrying about categories then actually figuring out what is most important to fix and fixing it. My tweets and this blog will echo that theme.

Most organizations use a defect rating scale of 1 to 4 or 5 where 1 is most critical and 4 or 5 is a minor or cosmetic issue. In all of my years of managing projects I am not sure I have ever seen a defect rated a 4 or 5 fixed. I'm certain a few have, probably by accident. So why do we rate them. The rating systems are used to help us determiner which are the most important or impactful defects that must be fixed.

Rather than rate theses defects 1 - 4 would it be better to identify the top 5 or 10 and work on those. When those are done, 5 or 10 more could be selected and so on.

By doing this, you are focusing resources on the most critical items and saving a bunch of counting.

"Less is More"

When you validate for a go live weekend make sure there are clear definitions as too how much needs to be done for validation. Today during go live the users processed a lot of work in a short period of time. Unfortunately the validation of each item takes a lot longer than the entry. Thus they could not validate everything in time to make the go / no go checkpoint. We are not sure if we have a problem because we really can't tell what should have worked because of the sheer volume done.  It is critically important that you plan how much work will make a good validation set and stick to it. More is not always good.

Listening is the best communication method

During go live weekends there will be issues found and some defects. When the users who are validating find these be careful not to go into explain mode. Listen to what they say and ask questions about the issue. Is it critical? What is the business impact? Is there a work around? Did this issue exist in production? The more you ask and listen the better the overall communication is which will result in a better outcome.

"Clowns to the left of me, Jokers to the right ...."

One of the most critical items of any go live is making sure you have the right resources for each task including validation. For example tonight we had the director of accounting and a senior underwriter look at policy output and invoices form the first validation cycle. They could very quickly spot issues that a developer or QA resource may not. So when you plan a go live event look at the tasks and schedule and make sure each has the key person or persons assigned. Then go back and look at implied items such as print jobs etc and make the right resources are also available.

Once More Into The Breach

So for those that follow this blog we are in the middle of our second attempt at a go live for 4 major projects. We incorporated lessons learned from the first go live weekend so what was a good plan before is even better with better timings. We are running ahead of schedule so one of the things we have to watch out for is to make sure people who thought their task was going to occur later are available when we are ready for them. Thus we are updating our status line more frequently and will call people when we kick off the next task which takes three hours to let them know to be ready to start earlier.

If you go off trail, carry a machete or "He chose poorly"

All thorugh the weekend everything was going well until Sunday morning when we discovered data issues. The cause was identified quickly and a plan to fix the records was devised. However this scenario had never been tested or done before so we were winging it. Unortunately we needed to restore afile and chose the wrong one. This caused more issues and caused us to backout the changes.

Got Me Again

Conversion ran all night and was almost done when it stopped. Apparently we forgot to shut down the backups this morning. Fortunately only 250 records left and we can restart from there. "Missed it by That Much"

Beware the Old Data

Just had a scare. As we were looking at the conversion we saw some anomalies and thought we had a big issue. Turned out that the records in question were some of the oldest . After reviewing these we found that we did not have an issue. But it does bring up another good lesson for converting data. Always look at both the newest and oldest records to convert to identify differences so they can be addressed in the conversion programs. 

Conversion 101

So it is now 8 PM Sat on go live weekend. We have finished our configurations and setup and are now in the middle of data conversion. The cool thing about this one is that the developer from our vendor who is responsible for the conversion has worked with us to test the heck out of it. We have executed over 30 full or partial runs of the conversion routines and validated each one. The data we are converting dates back over 10 years so the extra testing has really helped fine tune the programs. To me, you can never test conversion enough.

Press on Regardless

So last night we were way ahead of schedule. Rather than waiting we kept moving forward. Today one of the tasks we had took longer but because we had kept going we are still ahead of schedule. On big implementations buying yourself some extra time is crucial.

I Love it When a Plan Comes Together

The fun thing about go live weekends is that no matter how much you plan you just don't know what will happen till you get going. So far we are doing very well and are ahead of schedule. So now we are looking at the plan  and figuring out what impact on the schedule will be. This includes getting people to arrive earlier that originally plan to do their tasks. Communication is so important during the weekend. This includes taht everybody involved must be accesible.

And off we go!

The project go live tasks are underway. As usual we have some people who want to go faster but for the most part we are staying on the plan. On all of these implementations staying on plan is important. If oyu get too far ahead of schedule you could muiss tasks or dependencies.

Sometimes the plan does come together

Here we go. 4 PM on Thursday before go live and all critical issues are resolved and we are a GO for the weekend implementation. Today we scrambled to fix the check formats but they are done and the user lead is satisfied that we are ready to rock. Tomorrow morning will be spent making sure the legacy system tasks are all done and that the existing prod system is also free of any pended items. Check back all weekend for regular from the trenches updates.

If you are not sure, pick up the phone!

Here we are 3 days before the start of go live activities and once again a seemingly straight forward task has caused issues. We are upgrading the claims system to support another line of business. This line uses different checks than the workers comp product already on the claim system. Because of this and other requirements the vendor was creating a new check print function that will support multi drawer printing. A couple of weeks ago there was some concern that the vendor was not understanding the check layout so I sent a sample from the existing system. The sample had a top part and a bottom part. I was concerned with the top part which is the actual check. However when the vendor got the sample they took the whole thing as the requirement even though in the past our user said that the bottom items were not needed. This of course caused confusion and apparently extra work from the vendor. Now I will take responsibility for part of the confusion and have already told the vendor this. However, when the vendor originally got the sample and saw the extra items on the bottom, why did they not just call and get clarification.

This is the lesson from today. Yes we need to be clear when we send requirements to  the developer but if the item sent is different than what was discussed, they should call first and get clarification. This should be true throughout any project. If something changes that you are not sure of, pick up the phone and ask.Fortunately this incident should not cause us to miss the go live but it was a distraction that we did not need.

3 Days and Counting

So here we go. The project go live is this weekend. With Monday being MLK day we have three work days to finish getting ready and wrap up the final tasks! This week we will have additional training for the users. They had class last week but this week we will have one on one sessions to allow them to ask questions and go through particular scenarios. Our biggest task is to get the final setup for printing claims checks in place and tested. We are behind on this but the vendor has finished testing at their shop and we will start testing tomorrow.

"No, No Way, and No that is stupid"

We are one week from go live and had the Go No Go meeting with the users, execs etc today. Right now we are a go!. The funny thing today was that 30 minutes before the meeting I went to my key user and asked her if she had any issues to raise. She said no. The truth is she did and she raised them during the meeting which at first caught me by surprise. Once I got past that surprise we just got busy and made sure her issues were addressed and resolved. One of the issues she raised had to do with not being able to view comments that were converted from another system This surprised us as we could see the comments in the database. What had happened was that during training the lead user made a statement that they only wanted to see general notes so the instructor who also handles security set up changed the security profile. Thus the converted comments would not display. This has been fixed but it does lead to my title. At this point in the project had the instructor asked me if the change was OK I would have immediately said NO. If she asked again I would have said NO WAY. If she asked a third time I think you can figure out what I would say. This may seem silly to some but in reality it is critically important. At this late stage any change, no matter how small can lead to major problems. Thus all changes must be looked and reviewed carefully to make sure only the most critical are made.

Training Day

For the next two days we will be training the users on the application. The company has one training room so we are training a week earlier as that is when we could get the facility. To help the new users be ready for go live the following week we will conduct one on one training sessions next week. This will help the new users solidify what they learned in class.

"Icebound"

A good chunk of NC businesses are closed today due to the icy conditions on the roads and cold temperatures. Throughout the south people everywhere are stuck at home because of this mess. With technology many of us can work remotely which is what I am doing today. The3re are some people however that don't have the best remote access and they are having trouble connecting to the network to get their tasks done.

This brings up a very important point for the go live weekend (Which starts in 7 work days) With our vendor based in SC some of the vendor staff will be on site but many will also be remote either from their offices or home. Will they have good connections when we need them. Do they have a back up? For example if my modem cable connection does dead I can use my 3G wireless card. We need to be sure these questions get asked and answered before the go live starts and  find a critical resource is electronically MIA. We have already arranged for many critical resources to be on site.

So for any go live event ask the following:

• Who are the critical resources and where will they be?
• Should everybody come into the office?
• Do we have primary and secondary phone numbers for every resource? What about secondary emails (Sometimes believe it or not it is easier to get through on Yahoo mail than the company email)
• Are there back up resources identified for critical tasks?

8 days to go live

With 8 days to go the hope is that the the project is ready for go live. Code should be locked down by now or very close. All functions have been tested and all major defects resolved. Unfortunately many IT projects get to this point and have one or more significant errors that the team is frantically trying to fix. The question then is how long should this continue before we throw in the towel and reschedule the go live. There is no single answer to this question. In reality the answer depends on many factors including:

• Is the cause of the defect known and a fix imminent?
• What is the risk of going live vs. the risk of delay?
• What is the real and potential cost of the delay?
• Can the company be fined if the project is delayed?
• What bad thing happens if you go live and there is a major issue?
•  How much risk can the company tolerate?
• How much manual work is introduced if part of the application is not functional?
• Can data be corrupted?

I have heard the mantra from many executives that we will not go live with major defects. This mantra does not hold true because of the questions above. Instead of coming up with an arbitrary answer, look at the project and answer the above questions. Doing so will help you decide when to charge ahead and when not to be the Light Brigade.

Go Live is Tough Enough but did it have to snow

For the record my client is based in Raleigh, NC so snow ,sleet, or ice can be a disaster here. 9 days before go live and we are expecting all of the above starting this afternoon! So to make sure we stay on track we are already invoking contingency options for training, travel etc. Our vendor is based in SC which already has been hit so we are communicating with them and coming up with optional plans to deal with this weather event. This illustrates a very important part of go live planning, cancellation due to weather. No matter where you are at you can be faced with a weather issue or other calamity that may delay go live. For any go live plan you should include:

•  Always have an alternative date established in advance so people know what the contingency is.
• Criteria by which a go live would be cancelled defined
• Cut off times and dates to make decisions
• Communication plan

End of the week - go live is 2 weeks away

Actually we have 9 business days as the 17th is a holiday. Today we continued final UAT and review of conversion records. At the end of the day the project team and I did a review of what we got done and what we need to do early next week. I also met with our lead user resource to get her input. She stated she was a bit uncomfortable because some of the code tables were not loaded fully. This is actually good input because if she is concerned her staff will be also if we don't get these fixed. Fortunately these will be easy to fix and will be done by Monday. The lesson here is that at this juncture don't be afraid to ask for honest input and if it is negative find out why and what is needed to fix it. All things are important at this point!

Even the little things count now

11 days to go live and the project overall is in good shape. Today during testing we found a few security items and code configurations that were out of whack and will get those fixed for tomorrow. We have to be careful though to not treat these "little" things as little things this late in the project. With business users doing the UAT even these little issues can cause them to think the application is not fully ready. Thus as these things do occur the project team is jumping on them and getting them fixed as quickly as possible. Training will occur next week for all of the users so we must get to a stable state.

Go Live T - 12 days. Managing Dependencies

As the project gets closer to go live managing dependencies becomes a frequent and critical task for any project team. On our project we are dependant on another project to migrate our data to a new platform before we can convert to our system. We have somebody from our team spot checking the migrated data in the test system before and after we run our conversion to make sure the migrate data is correct.

13 Business Days to Go Live

The project I am on is going live on 1/24. It is a update to a claims system to support another line of business and includes a data conversion. I make the distinction between business days and days on the project as the work schedule is based on work days which should include contingency time. Weekends are not contingency but emergency time only. The only weekend that is planned as work time is the go live weekend which we already have planned out and are now just tweaking the start and end times. I will be blogging about this project and getting ready for go live regularly over the next 3 weeks. I hope you find this useful for your project planning.