This thought just came to me as I was having a discussion with my five-year-old son today.  He had just been fitted with his new glasses – his first pair – and he asked me when it was going to be nighttime so he could take them off.  It seems his eyes were very tired from getting used to the new change but he knew he had to keep them on and adjust to them till bedtime.  And he agreed that he could see much better now that he had his new glasses.

The true need was there…his vision was tested, it was found to be poor, glasses were ordered and now he’s on the path to seeing better…albeit with tired eyes.  But this scenario and discussion with Jack – our five year old – started me thinking about our own project vision – how we see things on our project and what ‘corrections’ we may need from time to time in order to see things more clearly, make correct assumptions and take proper action.  If we sit back and do nothing, we run the risk of not seeing everything or at least not seeing everything as we should.  What then?  Well, logic tells the experienced project manager that poor project vision can lead to bad estimates, incorrect planned tasks, effort focused in the wrong area and overall miscommunication happening on the project.

How do we improve our project vision?  Or more importantly – because it probably started out 20/20 at the beginning of the project – how do we get it back to 20/20 and in focus mid-way through a long engagement?

I realize this isn’t always a problem, but on long projects we can get unfocused – or at least focused on details that are taking our big picture focus off of the important things – like the end goals of the project and what we need to be doing to get to that successful end point.  How do we do that?  For me, it’s a four step process…

Step 1 – Revisit the project SOW / charter / mission statement

First, go back to the basic documents of the project – whatever you have or were given at handoff that tells the story of what the project is supposed to be about and what is the intended outcome/solution.  Meet with your team.  Are you on the right track?  Have you missed any details that you can see clearly now that were otherwise blurry or you were blind to at the beginning of the project?  It’s easy to overlook things…go back now and assess.

Step 2 – Sit down with the schedule

Next – and again with your project team…and the project customer if appropriate – go through the project schedule.  Review what’s been accomplished, what’s happening now, and what’s left to do for the remainder of the engagement.  Does the planned work still match up well with the project mission and statement of work?

Step 3 – Assess the customer

The next step is to meet with the customer.  If you feel like the project has gotten a little off track – enough so that you’re at this point where you feel you need to re-assess or adjust your project vision – then meet with the customer to get their perspective.  Do they feel the project is on the right course?  Any concerns as to overall focus, missed project requirements, concerns over functionality, or possibly any grumblings from the future end users and customer subject matter experts (SMEs)?  Now is definitely the time to air these out if any corrective action needs to happen.  By all means, make it now before it’s far too late and far too expensive.

Step 4 – Gauge the overall project health

Finally, taking into account what you’ve learned in steps 1 through 3 and including a review of the resource forecast and budget health and forecast, what’s the overall project health?  Is there more corrective action that needs to happen?  If project health is in any way poor right now – if any red lights are going off – make them known now and work with the team and customer to come up with corrective action.  Hopefully it won’t be necessary, but while we’re assessing and correcting our project vision at this point, it’s definitely a good idea to take stock of the overall project health and determine what tweaks may need to be made either in tasks, assignments, skill sets, or how the project is being run in general.

Summary

Into each project a little rain must fall.  And when that rain is heavy or contains hail or turns to snow, we can get off track – sometimes way off track.  Issues and risks get in the way and we need to do our best to get back on track and focused on what we were tasked to do.  Deliver a successful project to our project client.   These steps should help us get there…

We’ve been using a great product called Camtasia to develop videos and put them onto Youtube or deliver them to customers. We’ve created a 7.52minute video outlining the TeamHeadquarters product. It’s very fast, and it’s intention it to give you a quick overview of all of the functions inside of the THQ solution. A live demonstration can be arranged where we’ll discuss how THQ applies directly to the business issues your solving and the methods that you use.

Originally posted 2012-04-27 09:30:58. Republished by Blog Post Promoter

Occasionally I’m asked, “Are formal signoffs necessary?”

My take on this is, “Are you kidding me?” Do you want a receipt or some sort of documentation when you pay your taxes, mortgage, or rent?  Should you have a will that directs what happens with your kids and money if something happens to you?  Ok, lots of people don’t have a will in place but at least we all know we should.

And when we are working on, say, a $1.5 million project, should we not be documenting the formal acceptances of the work we do along the way toward full completion of that project engagement?  It’s how we know for sure that tasks and deliverables are complete.  Actually, it’s how we know for sure that the customer – who pays for these deliverables – accepts that they are complete and that formal acceptance, then, is how we justifying invoicing the client for the completed work and how we know that we should expect to be paid for that work.

What to get formal project signoff for:

For me, it’s critical to get formal signoff on four items or categories of project efforts:

1. All project deliverables.  This includes all upfront planning documents and any key deliverables throughout the remainder of the project.  These are usually documented in the project statement of work (SOW) document and indicated in the project schedule in the early planning phases and then throughout the project schedule as other key milestones and/or deliverables.

2. Change orders.  Getting a formal signoff on each project change order is extremely important.  It documents the customer’s acceptance of the estimate and basically their agreement to pay for the work that your delivery team is about to perform that has been deemed outside of the original project scope or requirements.

3. User acceptance testing.  A formal signoff after UAT shows that the customer agrees that they have thoroughly tested the solution and that they agree that it is bug-free and ready for deployment.  Without this formal signoff, any issues at the time of deployment could be in dispute setting the delivery team up for requested fixes and changes at rollout that they have no documentation to defend against.

4. Solution acceptance.  Finally, a formal signoff at the time of solution deployment says that ‘everything’ is done and that the customer agrees with this.  It may require a sit-down review of the project schedule vs. the project statement of work (SOW) to verify that everyone agrees that all proposed deliverables were, indeed, completed.  But your formal signoffs on each of those deliverables – as mentioned above – will help with this process.

The real reason for project signoff

This all brings us to the reasons for final, formal signoffs that we’ve been discussing.  First and foremost, it shows completion of the work on the project.  Having formal signoff says you think you’re done and the customer also thinks you’re done.  And even more importantly, the customer is satisfied with each deliverable and item they’ve signed off on to the point that they accept the work performed.  That’s critical.

Additionally, a formal signoff on every necessary item is good from a legal standpoint.  It may never be necessary, but if there is even one project during your career where there is a dispute about the work performed, having a formal signoff from the customer on any work in question will be of considerable help in any subsequent legal proceedings or arbitration meetings.  Trust me, you’ll want to have those signoffs documented in a project folder for safekeeping…just in case.

Summary

How formal you go on many project details often depends, of course, on several factors.  How complex the project, how large the project budget, the preferences of the project client, etc.  However, it will always be a good idea to ask for and obtain formal signoffs from the customer for the work that you and your team deliver to them.  In the end, it may not be necessary to have and it may be something you’ll never have to go back to or refer to, but having it means it’s always there if the need arises.  It’s good project management best practices and it’s just good business.

Consolidate applications for IT work management and reduce effort, cost and futz factor to the tune of 300%!

Typical assortment of IT Applications

IT organizations are overloaded with apps.  This graphics represents a typical sample of an organizations disparate IT work management application layer.  Each app likely has its own database.  Apps require maintenance and input and a cost to keeping the current.

It gets worse.

• Multiple installations and databases of apps used in different silos
• Apps installed by rogue IT staff that need/want them
• Home grown applications may be installed for each department
• Project management tools can include spreadsheets, open source applications and Microsoft tools.
• Add SharePoint or Wiki tools

When does this become unmanageable?

It already is unmanageable.  The real question is when does this become impossible?

The exact circumstance that leads to an impossible situation happens when the capability of the team to manage multiple data points breaks at a customer interaction point.  In other words the customer, “fell through the crack”.  Customer upsets increase and IT satisfaction plummets.  Cracks become chasms and change then must occur.

Be certain that at some point in the future the IT organization will shake apart for this reason and that this is what keeps the IT manager awake at night.

What to do?  Consolidate applications, eliminate duplication and redundant applications and data, and align your IT efforts with an IT strategy.  Easy to say, tough to do; isn’t it?  It sure is but this is a guaranteed win and an effort that the IT Manager can either choose to engage with or one that may be chosen for him.

The Benefits of Consolidation

Companies that eliminate, align and consolidate disparate IT management systems, processes and activities:

• Experience increases in customer satisfaction
• Improve employee morale
• Have fewer resource crunches
• Enjoy better acceptance within their organizations.

Consolidated IT Work Management System

TIPS FOR CONSOLIDATING IT WORK

• Start with ITIL
• Create a Strategy for ITIL
• Create a project
• Source an application that can streamline your IT department

How can TeamHeadquarters Help?

Consolidate your IT work with TeamHeadquarters.  Integrating project management, help desk, time sheets, resource management and more, TeamHeadquarters will streamline your IT work management.

Originally posted 2012-11-28 10:58:38. Republished by Blog Post Promoter

FOR IMMEDIATE RELEASE

Sep 13, 2012 — September 1, 2012 London Ontario / Dallas Texas

Forest Park Medical Centers visionary healthcare facilities of Dallas Texas are dedicated to delivering unsurpassed quality and cost-effective healthcare. When Forest Park IT set their high bar for the successful integration of help desk with project management it led them to the TeamHeadquarters product from Entry Software Corporation. Forest Park required a single system that would replace multiple applications in place for the management of help desk and projects. They needed everyone to work from the same system.

Entry Software proposed and implemented a single integrated system that would address the needs of all the IT workers in Forest Park’s various locations and effectively replaced separate applications for helpdesk, project management and customer self-service portal. With their closely developed five day implementation process they were able to complete the entire project, onsite within one week.

As a full-service, acute-care hospital Forest Park focuses on high-quality surgical services that include state-of-the-art, fully integrated operating rooms, an innovative imaging center and world-class surgical equipment pioneering today’s most advanced surgical breakthroughs.

Entry Software Corporation is a leader in providing effective work management solutions to various industries around the globe. Their product, TeamHeadquarters, provides unique solutions for IT, Product, and Service Departments. TeamHeadquarters creates value through cost reduction, improved operating efficiency, and enhanced customer communications.

For interviews and questions please contact John McDonald, Director Sales for Entry Software.

Originally posted 2012-09-25 14:26:03. Republished by Blog Post Promoter

This probably sounds like a strange question in the hopefully very organized world of project management, but it really isn’t all that strange. How do you know when you’re project engagement has come to an end?

Is it when all tasks in the project schedule show that they are 100% complete? Is it when all customer signoffs are safely tucked away in a project folder? Is it when the end solution has been deployed? Is it when your PMO Director says you’re done and assigns you to another project? (Don’t laugh…saw this happen once but that’s for another article.)

All of these – except for that last one – could logically be answered ‘yes.’ But they can also be answered ‘no.’ There is no perfect ‘right’ answer actually because each of these could still be followed and something could have fallen through the cracks. Knowing when we’re actually done with the project may vary a bit depending on the project, the customer, and possibly some stipulations agreed to during kickoff. To best ensure that the project is basically ‘complete’, follow these four steps…

Review the project schedule for completeness

For starters, look over the project schedule. Are all tasks showing as 100% complete? Without all tasks documented as complete in the project schedule – which should serve as the go-to resource on assigned project tasks that make up all things that were to be completed on the project – then we can never even begin to think of the project as ‘finished.’

Confirm with the project team

We certainly want to make sure that from a documented standpoint, all project work is complete. But we also want to make sure that we haven’t missed something that was discussed along the way. What if a project team member promised a task or document to the customer a couple of months ago. Since customer satisfaction is always of utmost importance, we want to make sure that any promises, documented or undocumented have been followed up on. Of course if its something significant, you’ll want to first check with the customer and confirm they need it and want to pay for it it’s out of scope. But always include this step – it may end up uncovering something that was important to the project or customer.

Discuss with the customer

Next, interview the project customer and make sure that they, too, consider the project work to be complete. Go through the project invoices with them or prior to this conversation to make sure all invoices are paid. Any outstanding invoices should be addressed with he customer at this time to ensure there is no reason that payment is being withheld.

Obtain customer signoff

Finally, the last step is to obtain a formal project acceptance or signoff from the customer. The other steps are really to help ensure that the customer is happy with the solution and that all stakeholders feel that the necessary project work has been completed. However, this official signoff really trumps everything else and is a necessary final piece to the project closure puzzle.

Summary

We can certainly make the project closure process a very rigid, structured process…and that’s fine. A good project checklist is always a great idea. However, by also following these steps you should really be able to ensure that nothing has fallen through the cracks and that the project is, indeed, complete.

SMB’s are struggling with the application of standards within IT.  Still considered a black art by business executives, IT Standards are often touted, seldom adhered too, and never perfect.  Let’s work through ITIL to establish the optimum / minimum required for any SMB IT Service Desk.

Originally posted 2012-11-06 13:51:02. Republished by Blog Post Promoter

What are the essentials of an ITIL implementation project?  You could use the ITIL five part process as your guide:

1. ITIL Service Strategy
2. ITIL Incident Management
3. ITIL Problem Management
4. ITIL Feedback Management
5. ITIL Change Management

Or, I suggest that you limit your starting project to ITIL Service Strategy, ITIL Incident Management and ITIL Problem Management.

You can’t get far without an ITIL Service Strategy. It will provide the team with a framework for decision making and a foundation for excellent, continually improving service.  Read more about this in my ebook - 4 Steps IT Awesome

ITIL Incident Management.  You really must have incident management.  It’s a core function of ITIL and the best way to go about it is to leverage the service book that you put together while developing your ITIL strategy. I’ve developed some simple steps for this and you can read more on it with my ebook An IT Managers Guide to Implementing ITIL

ITIL Problem Management will help you mature.  ITIL talks about problem management as the practice of resolving the root causes of incidents.  These can be understood through an examination of incidents, feedback from customers and change requests.  This whole process is referred to as Problem Management.  It’s critical to ITIL and will really help your organization mature and grow.

ITIL Feedback Management is great once you’ve got 1, 2 and 3 in place. I’ve worked through surveying and  and have developed some very sound strategies, questions and reports that you can download. Here’s a link to my blog post Help Desk Customer Satisfaction Survey Best Practice where you can download the survey questions and reports.

Download ebook – An IT Managers Guidebook to Implementing ITIL

What are the essentials of a good ITIL project?  Well it all is really essential but unless you have a sound ITIL Strategy, with effective and usable ITIL Incident Management and Problem Management processes then all the feedback and change management in the world won’t help you. Focus on items 1 through 3 above, master them and then you can spend your time on 4 and 5.

Good luck – contact me to discuss ITIL or tell me what you think.

This is sort of an age-old question in the PM world, isn’t it? What skill set or character traits do I need to become a good project manager? Ever individual who is considering entering the field should ask this question of themselves, their colleagues, and some PM experts. The field isn’t easy and it definitely isn’t for everyone.

As I’ve managed and succeeded and failed my way through about 20 years of IT project management, I’ve made mental – if not always written – notes of what works and what doesn’t and what qualities in a person seem necessary in order to succeed in this career. And while I’ve worked on this list more than once and it’s not the same every time, I can say that what I consider to be key personal traits or characteristics of a good project manager generally boil down to these four qualities. There are definitely more – and I’m open to your arguments, thoughts, and suggestions, but here’s my list…

Communicator. This is the top one for me. In my opinion being an efficient and effective communicator is the number one role the project manager must play. If you can’t communicate well with your project team, your project customer, and your senior management, then you shouldn’t be in this business. You’re going to get weeded out early or eaten alive during your first project kickoff meeting. During one requirements meeting I had a business analyst who was reduced to tears because that person was taking everything personally and not communicating requirements and expectations well or controlling the room. A good BA because of the combo of technical and business skills, but not project manager material. I’m still trying to block that project from my mind.

Negotiator. Issues arise on every project. I think every project I’ve ever run required scope changes and change orders. Negotiation is just part of the PM game. It always will be. So a good project manager must be ready to leverage business practices, technical knowledge, project status, and customer needs to keep the project headed in the right direction. It may require different resources, more money, a phased approach…whatever it takes it will almost always require some give and take…some negotiation. This is a key skill that must be there.

Confident leader. The project manager must exude confidence. I don’t mean an ego trip. But they must be a confident leader. I usually have a bunch of very talented technical people on my project team and they all have big egos. It helps to be technical when leading those resources…no doubt about that. But you must also be confident, take charge, and lead them. Otherwise your team will go over your head with the customer, with your management, etc. to get things done. You must lead them.

Stubborn. This may seem odd, but it is important. It is broad. You must be a good decision maker. But it goes beyond that. You must also be stubborn. Stick to your decisions. Why? Because everyone from the customer paying for the implementation down to the developer building it will question you along the way. If you’re weak and not stubborn, you could end up changing your mind many times and the end result will be a project thrown off track by an indecisive leader who isn’t long for this career path.

For more information visit the Entry Software site and signup for an online 30-minute demo with an Entry Software consultant.

About the author: Brad Egeland is an IT/PM & Business Strategy consultant and author with over 25 years of software development, management, and project management experience. He can be reached at brad@bradegeland.com or you can visit his website at www.bradegeland.com.

Originally posted 2011-10-28 10:17:23. Republished by Blog Post Promoter

Depending on the organization and the project, some project managers have a lot of input in how they plan and execute the project. There are often key decision points and planning inputs that can make a big difference in the end result of a long project engagement   And the information that we – as project managers – gather and the decisions and choices we make, definitely can serve to increase – or decrease – the overall likelihood of our project and team’s success in the end.

What are some of these choices and decision points?  I’m sure the list can go on and on, and I welcome input from our readers, but for me it’s mainly these four key areas:

1. Staffing the skill sets

Thoroughly reviewing the statement of work and identifying the right skill set for each key project team member resource is extremely important for the overall success of the project. Requesting too many resources or too high of a skill set will result in higher resource costs on the project.  Requesting lower skill levels that are inadequate for the tasks can result in poor project team performance.  Neither is good for the project as one is a budget concern and the other is a quality concern.

2. Involving the customer in the right tasks

Full customer engagement can often be a challenge. Most project tasks will be assigned to delivery team members. But the wise project manager assigns several ongoing tasks to the project sponsor and his team to keep them engaged on the project and keep them accountable. Making them do actual project work means less micro management by the customer.  Keeping the project client busy with project tasks keeps them in close communication with you, helps ensure that they regularly attended the weekly status meetings, and also can mean they are more available to you throughout the project engagement for those times when you need to reach out for a key piece of information or input on a decision that can’t wait.

3. Scaling the deliverables

Small projects don’t necessarily need every plan and document created. And even if you choose to create versions of every project planning deliverable ever conceived or if your customer requests them, they won’t need to be 75 pages for a 3-month project. Use the project budget wisely and look for places where deliverables can be scaled while still providing the necessary quality to the customer.

4. Proper risk management

Every project – big and small – needs risk management.  Upfront risk planning and identification and ongoing risk monitoring, mitigation and avoidance should be practiced…no matter what. The project manager and team who choose to ignore this critical practice are setting their project up for failure.

Summary

We can’t guarantee project success…but we can routinely make good choices for our project. And they are really the same fundamental choices on every project no matter the size, budget, duration or complexity.  Good choices and good decisions on how we manage our projects are all just part of basic project management best practices.