Project Insight Community

Project Insight Adds New Project Management Webinars

Janelle.Abaoag — Tue, 07 Feb 2012 16:27:00 GMT

Project and portfolio management software, Project Insight is partnering with Core Performance Concepts, Inc. to offer a refreshed curriculum of 23 unique project management webinars for 2012. This is the fourth year that Project Insight has joined forces with Core Performance Concepts to provide their customers and the general public with the opportunity to continue project management education at the convenience of their own desk. This year, the webinar series has been revamped with the addition of 13 brand new topics. Core Performance Concepts is a project management and leadership training provider and a Registered Education Provider (REP) of the Project Management Institute (PMI®), the non-profit standards body of the project management industry.

The project management webinars are offered twice a month, on the second and fourth Wednesday. The first webinar of the month is a fundamental course, which are basic project management courses that can benefit those without any formal training. It may also be used as a refresher for those already with a Project Management Professional (PMP®) credential for professional development units (PDU®) credits. The second webinar is an advanced course, for project managers and project team members with more experience. The advanced topics can also be used as a refresher and applied as a PDU®. New additions were made to both the fundamental and advanced project management training webinars.

"The Core Performance Concepts training webinars help project managers and project team members hone their skills and improve their ability to connect, collaborate and perform," says Diane Altwies, CEO, Core Performance Concepts. Upcoming webinar topics for the first quarter include:

February 22: Agile Project Management
March 14: Estimating Cost
March 28: Creating Use Cases
April 11: Human Resources - Managing Project Conflict

About Project Insight™

Project Insight, project management software, is powerful for project managers, easy for everyone. Project Insight offers a hosted or SaaS edition as well as an on-premise edition. Project Insight's software supports The Project Management Institute, Inc.'s (PMI) standards, and is compliant with the PMBOK® Guide. Project Insight and Metafuse are registered trademarks of Metafuse, Inc. Other brands are registered trademarks of their respective owners.

Dealing with Unethical Project Clients

BradEgeland — Mon, 06 Feb 2012 16:53:00 GMT

There’s no question that we are in the IT consulting business to make money, right? We can’t feed our family on fun and professional growth. The dollars must keep coming in – otherwise we have to start looking for something else to do.

Given that, the thought of turning down business is a hard thing to fathom – especially in this economic climate. Recovery?? We’re truly not there yet. It could be years...who knows? So, in the mean time we all struggle to remain viable while trying to pick and choose our projects and our clients – if we have that luxury – to the best of our ability. We try to only take on customers who seem reasonable, ethical, and won’t drive us insane. Does this sound familiar to you?

Hooking up with the client

Through whatever process you choose, you’ve hooked up with a potential client. It may be a situation where they found you from a professional article or professional posting or possibly you found them when you contacted their organization offering your services. Or even better, maybe they found you through a referenceable customer of yours. However it happened, it happened. And now you’re face-to-face with this potential client discussing their needs, high-level requirements and business processes and trying to determine three things: 1) is this work I can do, 2) is this a project I want to take on, and 3) is this a client I want to work with. You may have even started to draft out a project plan with your online project management software tool at this point. #1 is should be fairly easy for you to answer after a brief discussion with the potential client. The harder questions to answer are #2 and #3. You don’t know much about their business and their employees yet and you don’t know much about your direct customer contact. You have no idea if they are going to be easy to work with or difficult to manage. And you can’t determine really at this point if they are ethical or unethical.

I will say this – if you have a gut feeling early on that they may be unethical or you feel uncomfortable with them…don’t move forward. I can attest to the fact that, without exception, every time I’ve had a discomfort level with a client or even a direct employer and then moved forward with them anyway, I’ve been sorry.

You’ve made the wrong choice

There will be times when you determine that you’ve made the wrong choice. You’ve decided to move forward with a client who is or is going to cause you lots of headaches. You’ve had to add so much planning and other extra time into your web-based project management software tool just to accommodate them and their headaches. They may be unethical. They may refuse to pay for services rendered even though you’ve delivered good work. They may continually try to push scope but balk at paying more. They may call you at all hours of the day and night. Whatever the problem or frustration, you’ve realized you made a poor decision to work with them.

I had one client who I had misgivings about early on. The reason why I decided to move forward with the work is mostly due to the fact that I had maintained a relationship with this potential customer for six months trying to get to the point where they needed my consulting. When it finally happened, I ignored all of my misgivings and moved ahead. Bad call. They brought in clients and lied to them. They took them out partying and then discussed the lurid details during face-to-face client sessions with them. Too much Las Vegas fun, not enough professional work – and that’s not my style. And in the end, they abruptly ended the consulting engagement owing me over $2,000 in consulting fees. Unethical? Yes. Stupid decision on my part? Yes….I take full responsibility.

The exit strategy

So, if you find yourself in a bad client situation, what do you do? My recommendation, in order to not start bad word of mouth about your services, is to not end anything abruptly. Look for an out – possibly a key deliverable coming up or the end of a phase or milestone in the project management software schedule. At that point, make sure you’re paid up to date, and then break it to the customer that you have another pressing engagement and you can’t move forward any further on the project.

Of course, you must first ensure that you’re not breaking something in the contract that may leave you facing legal action. If that’s the case you’ll have no choice but to continue with the project. But if you can find and out, take it. And to leave things on the best grounds possible, suggest another consulting contact as a possible replacement – even if they may be remotely located in another part of the country. At least you’ll go out offering a solution.

Brad Egeland

Brad Egeland is an IT/Project Management consultant and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. Brad is a married, Christian father of 7 living in Las Vegas, NV. Visit Brad's site at http://www.bradegeland.com/.

Lifelong Learning as a Project Manager

DianeAltwies — Sat, 04 Feb 2012 06:33:00 GMT

So you think you are good at your job....You've received your PMP credentials and you are getting to work on some great projects for your company. You're enjoying your work and you've been able to implement some projects that have helped your company grow and expand.

Well, it doesn't stop there. I tell my students frequently that they need to think of themselves as a "consultant" even though they have a secure, steady job. Why you might ask!

Great consultants understand the following:

The job is temporary
Continued work with a current client relies on how well the project was delivered
Success isn't just about how well the project manager performs his/her job--it is about whether or not the project delivered the results expected
There may a moment where the project manager must CHOOSE to close a project
There is no expectation to be working with the same team twice

So why would this be important to a project manager that isn't a consultant? A great project manager must understand exactly the same situation. A great project manager must go into a project knowing that the work is temporary and that their performance is ONLY measured on the project deliverable and not on how well the project manager managed a risk register. A great project manager also understands that you cannot treat all teams in the same manner.

Because of this environment, a great project manager must be a lifelong learner and approach every project as follows:

Go into the project knowing that there will be something they don't know
Be a quick study on the industry and seek out those within the organization that can help navigate the nuances of that industry
Understand personalities and learn who the team is and how they have operated in the past. The project manager must be observant and respond to the slightest change in attitude or mannerisms of each team member.
Be fearless for their team. There will be times of conflict and every situation brings with it unique challenges. Willing to investigate and address appropriately is key.

Some of you may think that you have the answers, especially if you are in a corporate environment and working with similar teams and stakeholers day-to-day. I challenge you to be even more reflective in your own actions and seek out new ways of addressing the same issue. No two situations are exactly the same. No two teams inclue the same resources. Nearly all projects involve change and change management, and the changes being made will ALWAYS be different. Keep your eye on the goal, but be observant and reflective in order to navigate appropriately for the project you are on today.

Diane

Beating the Time Entry Blues

Janelle.Abaoag — Tue, 31 Jan 2012 16:34:00 GMT

Accurately tracking time against projects and tasks is a common challenge that organizations encounter. Finding project management software that has the ability to track time and generate reports to view time logged against particular projects and tasks the way you would prefer is a hurdle in itself. However, getting team members to actual input their time is half the battle.

I’ll even let you in on a little secret. As a team member over here at Project Insight, entering my time and submitting it in a timely manner was not an easy thing for me to adapt! Implementing any type of software has its challenges, and this one was my personal challenge. I can’t exactly put my finger on why I was (or still am sometimes) so terrible about it. It could be several things: lack of motivation, not liking the idea of stopping to update something every fifteen minutes or so, etc. So how did I beat the Time Entry Blues?

My projects are comprised of several small tasks that vary in length. Some will require fifteen minutes, and others take up to 20 hours over a month period of time. I have learned to rely heavily on using my Project Insight portal page. I’ve customized it to show only what I need to see- too much information can be overwhelming. Simplicity is the key to keeping focus on what is important.

While I am already promoting simplicity – here was a simple fix: setting weekly appointment on my calendar to submit my time. Sometimes, going back to the basics is exactly what you need.

Ask your boss why you need to do it. Besides the importance of accounting for your time and assuring that you’re doing what needs to be done…there is a reason. Having a thorough understanding of why is enough to be motivating in many situations. Are you being overloaded with too much work? Are you tasks or projects being underestimated in regards to how long it will take you? The questions are endless, and being able to track this information will provide you and your team with some answers. The result? Hopefully a more manageable workload and enjoyable and less stressful day at the office.

Janelle Abaoag, Project Insight

Make Good PM Practices Work for You

BradEgeland — Mon, 30 Jan 2012 16:38:00 GMT

Work smarter, not harder. That’s the saying, right? Words to live by. Seriously…it’s painful when we watch people around us making life or work harder than it needs to be just because they’re not using the processes or tools or help that is there before them. We see this in life, we see this all around us in the world, and we see it in work, too. Hopefully we don’t see it too much in ourselves, but I’m sure it happens.

As project managers, how can we work smarter not harder? What can we do to get our work done, make our teams feel like they are being expertly led, and let our customers know that we’re doing everything we can for them? For starters, we can use the tools and templates given us and not try to reinvent the wheel on every project. That means not just going our own way, but relying on others when necessary, and using shortcuts – good shortcuts – whenever possible.

Our project management work lives can be made easier, if we rely daily on the following…

Software tools

The software tools we use can be just about anything…but they must be good and do the job we need them to do. For me, that starts with a solid online project management software solution. Desktop or web-based project management software tool, it doesn’t matter, though hundreds of cost-effective and powerful web-based PM scheduling tools are out there so that’s an easy pick. It must be detailed, collaborative, and give the team and customer the information necessary to know their tasks and project status. And it must give the PM and management the reporting necessary to keep the project on track.

Beyond the necessary scheduling tool, something needs to be in place for resource forecasting and budget forecasting and analysis. Resource forecasting can be handled in the scheduling software, though I like to also utilize Excel spreadsheets to help me out with this task. The same goes for budget forecasting and analysis – Excel does the job nicely for me again. I update and revise weekly so I’m never out of date and if the project budget is in trouble I’m aware right away and can respond accordingly.

Templates

We avoid extra costs on projects by utilizing good practices we’ve already been using on other projects. The same holds true for our project schedules and project planning documents that we use in our project management software tools. Sure, they change from project to project, but they all start from the same outline or shell. Building a consistent practice that produces similar documents and project schedules on similar projects helps the organization gain consistency and show project customers that a mature PM practice is in place. It helps to keep project costs lower and customer confidence higher – thus increasing the likelihood of overall project success.

Colleagues

Finally, your peers. Utilize your peers to help you get work done or understand the work better or gain the knowledge you need to go through a current issue. When we fail to look outside ourselves for help in times of need, we often …well, fail. Whatever the reason…ego, afraid of looking weak or inexperienced, or just plain ignorance… we sometimes fail to ask for help. Indeed, it should be the first thing we think of doing. We all want each other to succeed, right? A PMO is in place to help everyone get the job done and hopefully learn from each other. Weekly discussions among the PMs at regular PMO group meetings helps, but it may not be timely enough for your current project needs. You can reach out to your PMO director, but you don’t have to wait on that person. Work collaboratively with those around you. If someone on your direct project team can’t help you with the issue or decision, seek out wise advice from a peer project manager. You won’t be sorry….or look weak.

Summary

A good project management office (PMO) exemplifies these concepts. It expects knowledge sharing and has processes in place to make that happen including regular team meetings, shared knowledge databases, and lessons learned practices. A mature PM practice also has reusable templates in place to make project planning and status reporting a less painful and time-consuming process. And, of course, it has in place a practical and powerful project management scheduling tool that will help the PMs in the organization manage resources and plan for tasks.

Brad Egeland

Project Insight Supports Armada Ltd.

Janelle.Abaoag — Tue, 24 Jan 2012 16:51:00 GMT

Project and portfolio management software, Project Insight helps the project team at Armada Ltd. manage its projects more effectively. Armada Ltd. is a world class provider of prevention, preparedness, response and recovery solutions for both public and private sector clients. Project Insight's online project software allows the dispersed project team at Armada to access their projects from any location.

Challenges
Before Project Insight, the project team at Armada used an in-house project management system; however, as the company expanded, they outgrew that solution. As a significant portion of their employees work from remote home offices, it was mission critical for all project information to be accessible online. The organization also needed a good way to track and report on time at a very detailed level. The Chief Operating Officer (COO) decided to find a more robust project and portfolio solution.

Solution
Armada selected Project Insight because the software:

Provides visibility across all projects
Gives a view into all resources and their rates
Allows team members to track time down to 15 minute increments
Provides detailed reports on all time and expenses on all projects

The project and portfolio software was implemented with a small team of project managers, but as the company expanded, so did the number of team members. The ease of use and intuitive navigation made Project Insight easy to implement for all employees, even those with less experience with new technology.

Results
Today, the entire project team at Armada uses Project Insight on a daily basis. Project specific reports are run weekly to evaluate the status of all projects across the company. The COO states, "These reports help Armada identify where we can save an extra few thousand dollars to keep us business focused and profitable."

Another benefit was realized with their QuickBooks integration. Previously, time entries were being manually calculated, resulting in a high number of payroll errors. Project Insight's integration with QuickBooks has reduced the number of payroll issues by 90%!

About Project Insight

Project Insight, project management software, is powerful for project managers, easy for everyone. Project Insight offers a SaaS edition as well as an on-premise edition. Project Insight's software supports The Project Management Institute, Inc.'s (PMI) standards, and is compliant with the PMBOK® Guide. Project Insight and Metafuse are registered trademarks of Metafuse, Inc. Other brands are registered trademarks of their respective owners.

See Less, Manage More

Janelle.Abaoag — Tue, 24 Jan 2012 16:31:00 GMT

It’s a new year in the offices of Project Insight and what better way to kick of the year than with brand new projects??? Yes, internally, we use our very own project and portfolio management software to manage the several projects we have going on throughout the year. Of course, like any other organization, we have unique projects that we take on a case by case basis. However, we have projects that continue throughout the duration of the year that require the use of recurring tasks or tasks that last up to weeks.

Without the ability to see the current status of a task or last comment made in the project management software, then I would be encountering a flood of hourly (not daily) emails and several face-to-face meetings each week! Just the thought of having to track down the other resource put on a task, or constantly checking in with my boss to see if something has been officially approved stresses me out- and that’s just from my point of view.

Most of my tasks are ‘recurring’ and part of year-long projects. The Project Insight Portal page and calendar view are what I live and breathe in to keep all of my tasks and projects in order. I can easily click on a task from my customized portal page to enter time, or quickly glance at my calendar to get a quick overview of what I have coming up. I think the main thing that has made this all extra easy for me is having the options to show what I want to see. I hear and read about how important flexibility in project management software is. However, I don’t think I really understood the exactly what they meant until my workload grew and filtering the information visible to me became a lifesaver. Just because I see less doesn’t mean that I can manage my work less efficiently. In fact, I think it increases my efficiency because the information that matters to me is all I see – no need to search or scan the screen. Sure, maybe I shaved a good minute or two off and those sound small, but trust me, it all adds up!

Janelle Abaoag, Project Insight

Ask the Project Customer the Right Questions

BradEgeland — Mon, 23 Jan 2012 16:43:00 GMT

We start every project off in some sort of euphoric state, agreed? Every new engagement – once you’ve actually landed the client – is a clean slate. As I say, “You’re only as successful as your last customer thinks you are.” So, each new project is a chance to prove yourself, improve yourself, or fix whatever you did wrong last time and do it right this time.

The key is to never go into a project with blinders on. Never go into an engagement thinking you already have the right answers just because you’ve already mapped out a very similar project with a project management software tool. Never kick things off with the client taking their word for it on what the real need or root cause of the problem is. Go into it with just as fresh a vision on solving the problem as you are going into it with that fresh outlook on starting with perfection and trying to keep it that way.

Our job as project managers is to be the expert and solve whatever need the client has. Certainly, if you want to cut corners and you don’t care about referrals or continued business with this client – or if you really don’t need the revenue that bad – you can take the easy route and just give them what they told you they want. Just go through the motions, layout what they want in your web-based project management software tool and manage the project. For example, if they are requesting an internal cloud infrastructure to handle an application that they are launching, you can certainly set them up with a private cloud to run their applications on if that’s what they said they wanted. Forget about scalability and the savings they might experience if they were to start off with a public cloud using, say, Amazon’s EC2 cloud offering to launch a product and then help them take it private later once demands levels off to a manageable – and forecastable – level. Just do what they ask for and move on.

But we’re professionals. We want repeat customers and we want our projects to go well. What’s more, we want to solve the ‘right’ problem, not just the ‘immediate’ need. Right? So, how do we do that – it’s not our business? Well, we ask questions. We dig, we interview, and we investigate. And never just take the customer’s word for it. For me, it’s generally a process that involves – to varying degrees depending on the engagement – the following four actions:

Document the customer’s perceived need

During your initial client meeting and probably at least during one subsequent meeting, you’re going to be discussing the client’s perceived problem or need. Take thorough notes, and then turn those notes into a formal document that you can then turn around to the customer for them to review and agree to and map it out in a draft schedule in your online project management software that shows the customer you understand the effort needed. Now you have a document – and a draft project schedule - that says to your customer, “This is what I heard you tell me about your need and this is what you agreed to as your need.” Granted, this is really still at the high-level requirements stage – more of a draft statement of work – but it will serve to draw a line in the sand on the project. Get client signoff on this document, if possible.

Identify the related core business processes

Now you must do some investigative work on the perceived need and how it relates to the business processes around it. If the need is for a new accounting system, then you need to understand the business processes in the client’s accounting department and how the accounting department interacts and serves other areas of the organization. The client may think they need an entirely new accounting system – great for your bottom line. However, the real need may just be some additional reporting. Great for customer satisfaction and probably repeat business because you saved the client unnecessary expenses.

Investigate how the end users are affected

Once you understand the business processes, you must then meet with the end users within the organization (and external to the organization, if applicable). The key here is to understand how the old system or process is being used and what needs aren’t being met – in the end users’ perspective. Likewise, since you are touching this process anyway, find out what their ‘wish list’ is because there may be some key changes they would like to see or will soon need that you could address now more cheaply than creating a completely separate project several months or a year down the road.

Document the real need and take it to the client

Once you’ve completed the first three steps, the hope is that you’ve got a much better handle on what the client really needs. If it matches what he originally came to you with, then that’s great. If it doesn’t, then you have some things you’ll need to work out with the client – especially if the ‘real’ problem or need is going to be considerably more expensive to address than his original ‘perceived’ problem or need.

Set up a meeting and have at least a draft estimate in hand for what you think it’s going to take to solve the need. Take all of your documentation from the previous steps so that you can show him the detailed processes you followed to get to this point as well as his own people’s responses and their thoughts on the issue and what they perceive the need to be. Most of all, be ready to defend your findings. And be ready to walk away from the project if he’s stubborn and you don’t want to find yourself implementing something he doesn’t need only to be blamed in the end.

Brad Egeland

Managing Projects - We All Do It!

Janelle.Abaoag — Mon, 16 Jan 2012 17:11:00 GMT

This past week was the re-launch of our project management webinars! I’ve been so lucky to have been working with such awesome partners for the past few years in putting these together. Over that time, I’ve seen the popularity of webinars increase dramatically. And the team here, at Project Insight was completely on board. Since then, we’ve managed to grow the amount of webinar series presented and more importantly- expanded the topics to beyond what may interest only project managers.

First, we covered the ‘PM Basics’ – or the fundamentals of what project management was. The goal is for anyone that uses project management software, to see a great benefit in taking the time to configure any settings and get to know a new product. But the quick realization that team members that are not project managers were also using our software. This forced us to think a little further outside the box a little. Portfolio and project management applies to several areas of an organization and each resource plays their own part. So the thought was, why not extend the training out to everyone else?

After that, the ‘project management’ webinars began to address leadership and communicating in the workplace as well. Both of those things are topics that anyone in a company can find useful and improve from learning. What’s even better is seeing the audience expand beyond only the project managers. I guess my boss has been right all along…project management is cool and whether you are formally called a ‘project manager’ or not – managing projects is something everyone does at some point in time.

Janelle Abaoag, Project Insight

How to Ensure that Every Project Customer is Referenceable

BradEgeland — Mon, 16 Jan 2012 16:14:00 GMT

The title sounds enticing, doesn’t it? The truth is, there’s no way to ensure without a doubt that every project customer will turn out to be a referenceable customer. Even if the engagement seems to be successful and you’ve hit on every requirement for the customer, that still doesn’t guarantee that the customer will give you a good reference.

Huh?!?, you say. How can that be? Oh, any one of a number of reasons could cause what should be a happy customer to be a customer who won’t give you a good reference even if no ill will was spoken. Among the issues could be:

Miscommunication during the engagement that soured their opinion of you or your team
They could be the type of customer who will never feel like a project manager is necessary or good use of their money (I’ve actually been in this situation myself) and they’re upset about how much they spent on your services – without saying anything
Your solution – while it meets the laid out requirements – doesn’t fully meet their end users’ needs and they quietly blame you and your team
Change orders – justifiably necessitated by customer needs and requests raised the price of the engagement and left them feeling like they overspent
A turned down ‘free’ request that was outside of the scope permanently soured their opinion and outlook and they’ve decided they won’t give you a good reference

Ultimately, it could be any one of a number of reasons that the customer won’t give you a good reference. Who knows…but sometimes it just isn’t within your control.

Really, the best you can do is be the expert project manager and delivery team that you were brought in to be and exemplify best practices throughout the engagement, including managing the project very well against the online project management software schedule that you’ve provided the customer with. By doing so you”ll…

A) give yourself and the project the best chance for success

And

B) show the customer you’re thorough and professional and raise customer satisfaction and confidence in the process.

What are these best practices? They’re simple actually – put yourself in the position of the client who is paying top dollar for a project team to perform work for them and you’re trusting the team and project manager to understand your wants and needs and deliver a solution to you that works and is useable. What would you want from you if you were them? You would want:

Thorough up front planning with detailed planning tasks laid out in your project management software schedule
A thorough review of your requirements and a project team that helps you through the detailed requirements finalization process
An expert project manager that tells you what to expect throughout the engagement and then delivers on those expectations
Regular weekly status reporting on the project
Regular weekly conference calls or face to face meetings with detailed follow-up on what was discussed and decisions and assignments that were made
A regularly updated web-based project management software schedule that lays out the project plan in detail showing progress along the way and who is responsible for what
Thorough insight into where the budget stands at any point in time and how your money is being spent

Summary

Again, there is no way to guarantee full customer satisfaction no matter what you do, no matter how far you bend yourself to meet their needs, no matter how many extra miles you go for them, and no matter how much free stuff you through in (though you really should avoid ‘free’ stuff at all costs, no pun intended). Control what you can control – and that’s how you conduct yourself and document your work and the project and the information you give to the customer. At the end of the day, be satisfied that you’ve done your best and in the long run the customers you want to be references for you likely will and the problem customers that you want to just go away probably will.

Brad Egeland

Snow White & the Seven Dwarfs – The Most Important IT Methodology Deliverable?

CameronWatson — Fri, 06 Jan 2012 22:47:00 GMT

Context

One of the questions I am asked most frequently is “What is the most important deliverable of an IT methodology”?

The simplest answer is “it depends”. The more appropriate answer is “it depends on the scope of the project, whether a project team has been assembled, whether the project has been approved, if user requirements have been defined, what the technical alternatives are, when the project has to be completed, if the business users have been trained, etc, etc, etc”.

Every project is different. Every project stakeholder is different. Every project team is different. Every deadline is different. The uniqueness and dynamics of these ever changing variables ensures the “deliverable” deemed “most important” will change as the project and project team evolves. When I am faced with this question I usually try and respond with a story about Snow White and the Seven Dwarfs.

Stew Anyone

Once upon a time Snow White had invited all of the dwarfs over to her place for dinner. The first thing to meet the dwarfs upon their arrival was the aroma emanating from the kitchen – its scent was delightful and they kept asking Snow White what was for dinner. After some coaxing Snow White revealed that she had made up a pot of stew.

The Dwarfs conceded that they did not know what stew was and wanted Snow White to tell them what the ingredients were. Snow White relented and said “my stew is made up of a number of things – roast beef, potatoes, carrots, yams, peas, barley, and celery.” Snow White then invited the Dwarfs into the kitchen to look into the pot as the stew simmered. The Dwarfs were so excited to see the stew and each of them kept telling Snow White they could not wait to try it. They all promised they would eat all of their stew.

After viewing/smelling the stew, Snow White told the Dwarfs to find their seats at the dining room table and she would bring the stew out for everyone to enjoy. The Dwarfs gleefully found their spots at the table and were eagerly awaiting Snow White to arrive from the kitchen. Snow White entered the dining room with a huge bowl of stew and told the dwarfs to help themselves to a serving while she went back to the kitchen to get the salad, the buns and to make sure she had turned off the oven.

Upon her return to the dining room, Snow White was pleased to see the hungry dwarfs devouring their dinner and asked if they were enjoying the stew. Their collective response was a resounding “yes!”. In hearing this praise, Snow White sat down at her place at the table to recognize a most disconcerting reality - Sleepy had only the roast beef on his plate, Dopey had only the potatoes on his plate, Sneezy had only the carrots on his plate, Happy had only the yams on his plate, Grumpy had all only the peas on his plate, Bashful had only the barley on his plate, and Doc had only the celery on his plate.

Upset, Snow White confronted the Dwarfs saying: “Why did you separate all of the ingredients in the stew?” Each of the Dwarfs responded with the same answer: “We each knew what we liked and knew we would enjoy our own if we separated the ingredients.”

Snow White got up from the table, went back to the kitchen and returned with another large bowl of stew. This time she served the Dwarfs herself – each receiving a plate full of all the ingredients. After a little encouragement each of the Dwarfs tried the new concoction – with every mouthful the smiles on their faces got broader and broader. The Dwarfs had come to realize that the combination of all the ingredients was the true secret to success.

Moral of the Story

Although an IT methodology is made up of specific and unique deliverables, its true value is best realized when the all deliverables are used together throughout the life of the project. An approved User Acceptance Test Authorization deliverable utilized at the completion of a project is no more or less important than the Project Charter that was created to initiate the same project.

Bon Appetit!

Cameron Watson

Cameron Watson is the President of QAIassist. QAIassist helps organizations increase and optimze their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget.

Pitfalls of Managing Government Projects

BradEgeland — Fri, 06 Jan 2012 18:35:00 GMT

Working on government contracts is great...seriously. I've done it in the roles of application developer, project manager, and IT consultant for more than 14 years of my 25-year professional career. It can be rewarding, very profitable, extremely structured, and fairly consistent. That said it, can also be boring, tedious, and bureaucratic.

One thing it definitely comes with are obstacles you won’t find in private sector project management. While public sector project management consulting can be profitable and sometimes turn into very long-term engagements, it can come with several risks, or pitfalls, that you need to look out for and plan for if you want to ensure ongoing compliance and profitability. The following are some issues I’ve encountered – and you might encounter – as you serve your government client. The list is not all-inclusive, so I would appreciate our readers sharing their own thoughts and experiences on the subject.

Liquidated damages

Perhaps the biggest concern – because it can come with huge financial risks – is the concept of liquidated damages. Depending on the engagement and the sensitivity of the data or system that you are implementing, you could find yourself in a situation of being fined liquidated damages if the solution your are implementing is not ready on time. Yes, you do everything to manage tasks for the project using your online project management software, but that’s no guarantee that tasks will finish when they’re supposed to, as we all know. If you’re bringing up a new internal timekeeping and reporting system that is replacing an outdated legacy system, you likely won’t find yourself in this predicament if you miss your promised implementation date by three weeks. There likely isn’t big money riding on its timely rollout. However, if you’re implementing a system that will be used by the public and has financial implications such as college financial aid processing or social security payments, then you may find yourself at risk in the sum of tens or hundreds of thousands of dollars. The key is to read the fine print up front and determine if you’re up to the task and the risk. And carefully plan out project schedule – being too aggressive on a sensitive contract will not work in your favor.

Records archival

When you’re working on a government contract with lots of data – especially hardcopy data – you might find yourself with unique revenue generating opportunities as the contract winds down in terms of records archival and the development of any necessary record retrieval mechanism or process. These are additional tasks you’ll build into your web-based project management software schedule. However, if you haven’t properly mapped out this effort so as to understand the full nature of the task, you could also find yourself having underbid the sometimes arduous task of archiving the data and records – as per government requirements – to a federal records storage center and end up losing money on the entire engagement. Most federal records of a sensitive nature or that need to be potentially retrieved after a contract is over need to be stored in one of several official designated federal records storage facility for several years after the contract. Know the requirements up front, ask questions, and be sure to price the effort accordingly. I’ve had to go through this effort for millions of documents on multiple projects and it’s no small task by any means.

Approvals

If you’ve ever been to court, adopted a child through a government agency, or even just gone through the process at the DMV, you know that with anything related to the government there is the whole bureaucratic red tape issue. And it’s really no different when you’re working on a government project. Approvals on deliverables, change requests, and decisions in private sector projects can be sometimes time consuming and troublesome. They all must be built into your project management software schedule so you can track them and know when they need to happen. However, with government contracts you are often faced with increasing that timeframe tenfold. Key individuals may be out of reach, unavailable, or unable to make approval decisions in a timely manner. It’s critical that you define the approval process up front for any decision points in the project and document how long the maximum approval timeframe will be. That will help your project stay on track and keep your budget from getting out of hand as you twiddle your fingers waiting on approvals so that you can move on to future tasks.

Summary

It really is a give and take. In private sector consulting, things can move fast, decisions happen when they need to happen, and technology is often bleeding edge. Working with government agencies can bring security and long-term profitability. But it can come with expenses in the form of headaches, processes that don’t seem to make sense, customer decisions that seem to take forever to run through the proper chain of command, and the ever-present bureaucratic red tape. If you’re only familiar with private sector consulting and decide to venture into government contracting, go into it knowing that they are not the same and you’ll need to be careful when bidding your work because changes never happen on the fly. Get it all right the first time.

Brad Egeland

Take Away the Risks

BradEgeland — Tue, 03 Jan 2012 17:07:00 GMT

I’ve run ‘projects’ both as a project manager working directly for an organization as an employee and as a consultant brought in to either lead a team or perform the work myself. How you run these ‘engagements’ does differ somewhat based on your incoming status (employee vs. consultant) and the size of the effort (long-term software implementation vs. short-term consulting gig to implement new processes).

The upfront formal planning documents that we put together will differ, sometimes even the way we formalize and document requirements will differ. But one thing that should remain constant – albeit sometimes in a less formalized manner – is the act of risk identification and risk management.

Risk identification

Even if it’s a one on one engagement with the CIO of the organization, it’s still critical that you run through a risk identification process. It is critical that you plan risk identification and management activities into your project management software schedule. Remember, you’re coming in cold – this is not your organization so you don’t have some of the intrinsic knowledge of internal process and potential risks that a direct hire employee would already have. There are certain assumptions you may want to make that would actually only be adding even more risk because you’re not familiar with the organizational infrastructure and procedures. Or even the personnel for that matter.

Sit down with the CIO/sponsor and have a detailed risk planning session. He knows the organization so he’s your best initial source of information, but the onus is on you to ask good questions because you understand how a consulting engagement like this works and the common potential pitfalls that may be encountered. And based on what comes out of this meeting, you will likely need to update your online project management software schedule with some new tasks, assignments and dates.

The next step is to meet with others in the organization – subject matter experts (SMEs) and end users (if these are different people) and other personnel who will be interacting with the solution to some significant degree. These individuals can be good sources of information when trying to identify potential risks.

Risk strategies

Next, work with the sponsor and these same individuals to document the best strategy to mitigate or even avoid these risks should they arise. Even if you can’t formulate a detailed risk response to each item, identifying some strategy to keep in mind as you continue to track these risks will be helpful just in case.

Risk management

Finally, I’m a proponent of managing the consulting engagement on an ongoing basis much the same as you would a formal long-term project. Conduct weekly status meetings with the client, deliver a revised task schedule from your web-based project management software tool every week, and create and deliver a status report that will drive your weekly meeting with the client. And, in order to keep risk management at the forefront – make your risk list part of this weekly status report and revisit it – at least to some degree – on every weekly call with the client.

Summary

We may not always conduct smaller consulting engagements with the same formality as we would $2 million dollar projects for Fortune 500 companies, but the need to identify and manage risks is still there. It doesn’t take that much time and it’s so often overlooked, but mitigating even one risk that arises could mean the difference between success and utter failure as well as future business with this same consulting client.

Brad Egeland

Should the customer be involved in every decision?

BradEgeland — Tue, 27 Dec 2011 15:52:00 GMT

In an open, honest, everything up front, good solid working relationship with your customer engagement it might seem like the obvious answer to this question is yes. But let's think about this a little more. Does our client need to be involved in everything? Do you involve your customer by telling them every minute detail and asking for their input every inch of the way and on every decision? Really? And how is that working for you?

Here's why I ask. Your organization is the hired gun - the experts charged with making the project happen. It's your expertise they're looking for. It's your recommendations they want. And if they really wanted to make all the decisions they probably would be running the implementation on their own, right? The would.

So what do you tell the customer and what do you just figure out on your own? Here are some things to consider when trying to decide if it’s your call, if it’s the customer’s call, if you need to make a joint decision, or if you just need to inform the customer after the fact.

Does it impact requirements?

Certainly, if an issue arises that significantly impacts the requirements that you and the customer have already finalized, you need the customer’s involvement in making that decision. Let’s say you’re implementing a new accounting system and they have a reporting requirement for accounts receivables that you’ve just found out cannot be completely met with the proposed solution. If you can do a workaround that will provide them with the same information on the report but in a different format or layout, then you really won’t need their involvement. However, if the solution requires multiple reports where there was only going to be one or if you can’t give them the right information without some costly customization, then it’s going to significantly impact your online project management software schedule and you need the client to become involved in determining the new best course of action to take. It’s affecting their end users and most likely their end users will need some say in the decision.

Does it impact the budget?

If an issue arises that affects the budget or the dollars allocated to a particular task by more than, say, 5%, you will probably want the customer involved in the decision. However, if it is small and has little to no budget impact and you’re willing to ‘eat’ the difference or feel it will easily be made up somewhere else, then the best action to take is to document the chosen route but don’t bother the client in the details of the process.

Does it impact the schedule?

The budget scenario mentioned above applies to the schedule issue as well. If the impact to your web-based project management software schedule is so small that it can easily be consumed through expediting another task, then it’s best to move forward without taking the time consuming route of seeking out the customer for a decision. Our clients like it when we take the bull by the horns and make expert calls when there’s really no significant impact to the project. Getting tied in to every decision is not usually what the customer wants.

Is the solution going to be impacted?

Will the final solution and its usability be impacted by the current issue? If so, then the customer’s end users need to be involved and, yes, the client must be involved in the decision. But if there is basically no impact to the final working solution, there’s no need to alarm the customer. Document the issue, document the action you took, put it in the status report, and mention during the next status call.

Summary - just be accountable

The bottom line really is that you must be accountable. If you’re making the decision, own it. Don’t blame it on someone else. Because there may be times when you make a decision and it’s the wrong one or you find that you should have included the customer in the decision-making process but you didn’t. You’ll have to own those situations and take full responsibility for them and for their impact on your project and the impact on the project management software schedule. And also whether you include the customer in the decision or not, it’s always a good idea to document those decisions in your status reports to the customer so that you have them documented in case a follow-up discussion needs to take place or in case you end up needing to refer back to a particular decision later in the project. You’ll get a feel throughout the project as to the level of involvement the customer wants in some of these decisions from their reaction to the action you took. Look for clues as to their satisfaction with and respond to how you handled it. Openly discuss it with them. You’ll usually be able, then, to figure out the threshold of involvement they want going forward.

Brad Egeland

Born or Made? How do you become a good manager?

DianeAltwies — Wed, 21 Dec 2011 01:12:00 GMT

Recently a client of ours wrote an article about whether or not good managers are born or made? It had me thinking and I wanted to share my thoughts.

Many of you reading this blog post are project managers trying to navigate through an ever changing, ever diverse set of situations and sometimes it may feel overwhelming. Sometimes, no many times, it feels like the person at the helm can do nothing right. If we succeed it is because of the team, and not the leader. If we fail, then we take the sword for our team.

"History indicates that some people were born to have the ability and traits to be good managers. Evidence and research indicate that most successful managers do use proven skills and techniques that bring their abilities to the forefront. If good managers are born, then is he or she born with a kitbag full of tools such as a Requirements Traceability Matrix, Precedence Diagramming, Rolling Wave Planning, Critical Path Analysis, Critical Chain Method, Resource Leveling, Network Diagrams, Analogous Estimating, Variance Analysis, SWOT Analysis, and Trend Analysis; to name a few." Read the full article by Dr. Jay Braden, Director of Professional Development Programs for Stetson University's Celebration Technology Programs http://coreperformanceconcepts.com/partners/bradenarticle.html

A true leader understands that it is a thankless job and is willing to continue to build their skills and continuously improve. This improvement comes at a price -- you cannot expect to be recognized for your individual accomplishments...it is the personal satisfaction to know that you performed to the best of your ability in the role that you performed and took advantage of all tools available to you in your own personal tool belt. Good managers and leaders are willing to be accountable for the opportunities presented them.

What do you think?

Rebounding from a Failed Project

BradEgeland — Mon, 19 Dec 2011 17:24:00 GMT

Many studies have been conducted concerning failed projects and how many projects actually fail. Nearly all put the percent of failed projects in the majority – above 51%. Several recently conducted and well-regarded studies put the number somewhere between 62% and 75%. That’s saying that 62% - 75% of all projects fail. Ouch. But on the bright side – you’re not alone … it’s not just you. But that really doesn’t make it any easier or any better, does it?

So, going with the majority, let’s say your project has failed somehow. It may have finished over budget. It may have gone way off the timeline and no amount of tweaking the online project management software schedule will get it back on track. It may have delivered a non-working solution for the end user. Or it may have been canceled altogether in midstream either by the customer or your own organization. At any rate, you have a project that failed to some degree and likely a frustrated customer, displeased senior management team, and a staff of project professionals that think they wasted the last 6 months to one year of their professional lives.

What do you do to rebound from that and to help others on your team rebound from that experience? And what do you do to help ensure that next time isn’t a repeat performance of this project? For one thing, we do not bury our heads in the sand or try to sweep it under the rug. That which does not kill us makes us stronger, right? Let’s learn from the past – learn from our failures and the failures of our projects so as not to repeat those same failures again and again.

Here are three key steps to take to help ensure that going forward we realize greater successes on our future projects:

#1 – Have open communication with your team on issues

Whether it’s your own budget concerns, morale issues, or rogue behaviors of a team member – make sure you discuss concerns. If appropriate, do it one on one, but for most project discussions, conduct them as a cohesive team. The more everyone is in the loop as a team the more everyone can help to rectify issues before they get out of hand.

This applies both during a project – especially a troubled one – and after the project to learn, as a team, what everyone considers to be the issues that negatively impacted the project. Be sure to build these meeting points you’re your web-based project management software schedule. Consider it somewhat of a pre-lessons learned exercise. Take this information forward as you prepare to meet with your customer post-project to conduct lessons learned sessions.

#2 – Take issues to your customer early

Be sure to take any issues that arise to your customer as early as possible. If you need to discuss first with your team – as you should anyway for planning purposes – by all means do so. And if you need to discuss with your executive management to make sure they are aware and are backing you, then you should do that as well.

Always remember that the project is for your customer. They’re paying for it so they definitely have a stake in its success. They do not want you to fail – so get their buy-in and aid on issues and issue resolution. Put them to work. Build a two-sided cohesive team with the your team and the customer’s team and you’ll greatly increase your chances of project success.

#3 – Conduct lessons learned sessions

I’ve conducted surveys in the past on project management practices including the use of lessons learned sessions. Sadly the results did not looking good. Most responders state that they conduct lesson learned sessions 0-10% of the time. Many emphatically stated that they have never conducted lessons learned sessions. Often the main issue is they never blocked out or planned the activity in their project management software schedule.

What this also tells me is that we are doing a poor job of figuring out what went wrong and brainstorming with our team and our customer as to how we can do it right next time. How can we ever fully get it right next time if we fail to figure out – or even want to figure out – what actually went wrong this time? If we don’t identify what went wrong then future successes may just be out of pure luck.

Conducting thorough lessons learned sessions with our team and our customer will help us rebound from our failed projects with new knowledge on how and why we failed and how to prevent that the next time around. After all, there are often some degrees of similarity in the projects we manage and learning valuable lessons about our failures can help us to succeed next time with flying colors.

Brad Egeland

Should Project Managers Care About Green Practices?

BradEgeland — Tue, 13 Dec 2011 17:40:00 GMT

This is actually an interesting question. As PMs we are generally charged with carrying out the project according to the requirements that were agreed to at the beginning of the engagement. Rarely, if ever, do we have full rein on how a project will be developed and run and implemented. While we are professionally obligated to do our best to serve or customers and our organizations, that usually does not include substituting - on our own - green practices and technology that can have a significant impact on the final solution, the budget, or the timeline for the project. It just doesn't happen that way. It's a project, it's the customer's project, it is certainly their money and how the entire solution is developed and implemented is never going to be left up solely to the project manager to decide.

Now, with that said, do you think that project managers have an obligation to the environment and to the customer to incorporate green practices throughout the project that won't have a direct significant impact on the solution? I'd really like to hear from our readers on this. I personally feel like we do. I think of it not as best practices for project management but rather best practices for the environment. What are your thoughts? And furthermore, what can we – as project managers – do on our projects to incorporate those best practices for the environment? How can we make a difference without really ‘making a difference’ – meaning disrupting or changing the course of our project in the process? What tasks can we plug into our project management software that will show environmental sustainability action is taking place?

Here are a few thoughts I have on the subject and/or practices that I have put into motion on one or more projects in the past:

Go electronic

We can focus on electronic communications and electronic delivery of all or most deliverables. Gone are the days when a 150-page functional design document needs to be printed, boxed, and mailed or handed to your customer. That is the case – as well – for all or nearly all of the deliverables on your project. I led a project awhile back that lasted for just over 6 months, had more than 140 conference calls, more than 1400 emails, and not one printed document. I created and revised project schedules at least weekly – meaning more than 25 times – using my web-based project management software solution, but never once printed a schedule even for my own review.

Work in the cloud

Go web-based with software and software solutions when possible. Collaboration is easier when you use online project management software so that’s just a nice plus, but it’s cheaper, it’s greener (less equipment, licenses, server space, personnel for support, etc.), and it’s available anywhere for any machine you’re using at the time. The same is true with all other web-based software and cloud storage solutions.

Manage virtually whenever possible

Managing the project remotely – and allowing your team to work remotely – reduces pollution from driving, increasing worker productivity, reduces your carbon footprint by requiring less office space in the corporate headquarters, and reduces the consumption of fossil fuels in the process.

Limit travel

That same project I mentioned up in the first point also resulted in zero travel even though it was a critical project for the Department of Defense. And it was a very successful project with a very satisfied customer in the end. As long as you manage the customer well and communicate in a timely, effective, and efficient manner, then you don’t need to always be sitting in front of them. And if you can show extreme value to the customer without using a lot of their funds on your travel and your team’s travel, then you’ll definitely win customer points.

Summary

We can’t do everything on every project to promote green processes. We’re bound by what has been paid for by the customer, what the customer’s preferences are, and what the specific needs of the project are at any given time. We can, however, run our projects with one eye on how and if the environment is being affected and ask ourselves at each phase or at periodic points in the engagement, “Is there anything I can be doing or having my team do right now that will help the project and our efforts be more environmentally sustainable?”

Brad Egeland

Why User Groups and Conferences are Worth it – Part III

Janelle.Abaoag — Fri, 09 Dec 2011 15:39:00 GMT

This past week, I ventured off to Colorado to run a Project Insight Denver Users Group. It was a huge success and while I’ve already given my two cents on the importance of user groups, I’ve realized another reason why they are important during my flight back home. If you think I’m going to write about how it’s an excellent way to get your customers to tell you about how much the love managing their projects in your software or give you frank feedback on the latest additions – you’re wrong. And if you think maybe I’m going to elaborate on the topic of how finally being face-to-face with people you email or call on a regular basis does wonders for your relationship (which it really does), once again – you’re wrong. So then what exactly did my epiphany consist of?

The most genius and inventive ways of managing projects and collaborating using Project Insight come from the customers. I walk into these user groups excited for the different organizations to learn from each other and share ideas. But I realized that just because the team here develops the software and even manages every single project within it too – it doesn’t mean that we know it all! Here, at Project Insight, we work with companies of every type and each one manages projects in their own way. After simply listening in on the various types of projects, I was most interested in learning about how the software is used to prevent mission critical mistakes that could be extremely costly, or how truly effective managing resources schedules can be. Nothing makes me happier than knowing that our project software has made project management (and business life in general) something more enjoyable in the long run.

Janelle Abaoag, Project Insight

“IT Methodology” – what’s in a name?

CameronWatson — Wed, 07 Dec 2011 23:30:00 GMT

From its inception Information Technology (IT) has recognized the significance and importance of developing and applying a set of “standards”, “methodologies”, “lifecycles” and “best practices” that can be leveraged by its practitioners – the underlying objective has always been to increase the efficiencies of IT resources in the field. As the industry has evolved, the technologies have become more complex, increasingly faster, and forever changing, however, despite all of these advancements the IT industry remains in a self induced dilemma surrounding some of its most basic terminology.

To prove this point all we have to do is identify an unbiased audience of IT practitioners, establish a reliable sample population of that audience, ask the same specific question to each individual of the sample population, and document the responses provided by each individual of the sample population. With this approach in mind I recently attended a conference of several hundred IT professionals and practitioners. Attendees at the conference included senior management, business stakeholders, project managers, business analysts, architects, programmers and testers. My goal was to obtain a true and reliable perspective of what IT professionals understood the term “IT Methodology” to mean.

Applying these parameters I began on my quest. I set a target of speaking to 40 independent IT practitioners with a minimum of 3 years of IT experience – the population of 40 IT practitioners consisted of senior managers, business stakeholders, project managers, business analysts, programmers, testers. The following question was posed to each and every one of them. The question - Is “IT Methodology” a noun or a verb?

Without exception, all of the individuals asked the question were aware of the term “IT Methodology”.

50% of those who responded said an “IT Methodology” was a noun – they cited PMI Project Management, IBM’s Rational Unified Method (RUP), Prince2, QAIassist Integrated Methodology as some other methodologies they had used
30% of those who responded said that an “IT Methodology” was a verb – they cited their experiences with delivery approaches such as waterfall, agile, RAD, prototyping and spiral
10% of those who responded said that an “IT Methodology” was both a noun and a verb – they cited both of the above mentioned responses
10% of those responded would not commit to stating whether “IT Methodology” was either a noun or a verb – they were not sure either way

Suffice it to say, these collective responses were not what I had anticipated, they left me somewhat puzzled and concerned from a number of perspectives.

After giving these “unofficial survey” results a couple of weeks to resonate (and getting away from the emotion), I have taken it upon myself to try and articulate why the results of my “unofficial survey” were so disturbing to me. I have created the following examples to provide a context for the discussion.

Example I – Flying a Commercial Jet

Two pilots are scheduled to fly a commercial jet full of passengers from New York to London. The pilot is experienced and well trained; the co-pilot is new to the profession and learning on the job. During take- off the pilot guides the plane down the runway and safely elevates it into the sky. During the flight the pilot decides to catch 40 winks and hands control over to the co-pilot – he then drifts off into gentle slumber. Forty minutes later the pilot is awaken by the jolt of his seatbelt harness locking him into his seat – it doesn’t take him long to realize the co-pilot has lost control of the plane. Instinctively the pilot grabs the stick to resume control and take the plane out of its spin – he starts issuing directions to the co-pilot who is seeking to right the ship. The pilot says “full left rudder” and the co-pilot puts down the landing gear – the pilot says “drop the passenger oxygen masks” and the co-pilot jettisons the fuel tanks – the pilot says “pull your nose up” and the co-pilot glances toward the ceiling.

Example II – Performing Heart Surgery

A patient is brought into the hospital Emergency Room – problem – patient is suffering from chest pain and possible heart attack. A seasoned doctor and an intern are working the shift together and are immediately called to address the emergency. As the patient is put on the gurney the veteran doctor asks the intern what the patient vital signs are – the intern responds with a blank stare saying “vital signs -what are they?”. The seasoned doctor then asks for the heart rate of the patient and the intern says “does that mean how many beats per minute?” The veteran doctor then requests the “paddles” and the intern responds with “I left them at the cottage”

The point I am trying to make is not about flying a commercial plane or performing open heart surgery. It’s about why there is such a disparity in how and why IT professionals are not compelled or responsible for establishing and applying a common terminology that could be understood and expected to be applied by everyone in the field. Although un-verifiable (even with my “unofficial survey”) I suspect if the IT profession ever took it upon itself to work toward a common terminology it may reduce the number of errors found in applications, it may reduce the time a project team needs to deliver an application to the production environment, it may increase a project teams ability to design an application that meets the user requirements, it may improve the communication and understanding between business subject matter experts and IT practitioners, it may ensure an organizational process could be implemented and relied upon to consistently deliver products, services and operational efficiency.

At the risk of providing the correct answer to the “unofficial survey” question while being perceived as clogging the ever spinning wheels of IT terminology – an “IT Methodology” can be used in the context of both the “noun” and/or the “verb”.

Cameron Watson

Project Insight Supports Seoul USA

Janelle.Abaoag — Wed, 07 Dec 2011 21:45:00 GMT

Project management software, Project Insight, provides Seoul USA with the ability to communicate and collaborate effectively on projects. Seoul USA is a non-profit based in the United States and a non-governmental organization (NGO) in Korea. The team at Seoul USA manages a ministry that works with American churches to provide religious education to the persecuted churches in China and North Korea. Project Insight’s user friendly and scalable project management solution has made it simple to add...(read more)

Maintaining Control of Your Projects

BradEgeland — Mon, 05 Dec 2011 17:28:00 GMT

As we go about our processes of managing all of the projects on our plate – and often that can mean organizing our activities across four, five or even six live projects at a time – maintaining control of those projects can sometimes be an issue. Keeping projects on track, organizing the team and keeping them focused, and making sure the customer has the information and attention that they need and deserve can be a difficult process.

There’s no easy answer on how to do this and often how you react to issues that come up as a project becomes a challenge is based on what that challenge is, what type of project it is, and just how critical the issue is at that moment. Therefore, there’s no real standard way to describe going about maintaining control of your projects during those troublesome times. What we can look at, however, are some PM best practices that we can ensure we are incorporating so we’re less likely to experience those project-going-out-of-control type issues.

From my experience, ensuring that these four actions are taken during the project can greatly decrease your likelihood of seeing significant project issues and, therefore, increasing your likelihood of maintaining ongoing control of your projects…

Don’t skip the planning details

Don’t skip the up front details. Project planning documents like the communication plan, the risk management plan, the development plan, the procurement plan, the change control plan, etc. may not seem necessary, but for most projects creating some or all of those up front plans is important to create stable and well-documented projects. Those documents provide customer confidence that the engagement has been thoroughly planned and also provide a point of reference for the rest of the project.

Make risk analysis part of the planning process

Sitting down early with your project team and customer to analyze risk may seem like a waste of time on a critical project with a tight budget. After all, risks that turn into real issues are just issues you deal with on the project. They’re just part of the process, right? Wrong! Always spend at least some time going through a risk identification process. Put key risk management tasks in your web-based project management software schedule.

It’s best if you examine all potential risks in detail – giving each a weight and planning how to avoid or mitigate each risk. But just identifying the potential risks is helpful. It means you’ve thought about them and you have them in your scope and you’ve documented them and you’re somewhat prepared to deal with the risk should it present itself as a real issue. Being prepared helps you maintain control of the project.

Check and recheck requirements

Requirements are the lifeblood of the project and a project that starts with poorly defined or sketchy requirements is almost assuredly doomed to experience rework and possibly failure. Revisiting the requirements early in the planning process to ensure that they are detailed enough to work from can save enormous amounts of time and money throughout the rest of the engagement. And ensuring that what you are developing from is going to provide the solution that your customer wants and needs will help you maintain control throughout the engagement by avoiding some major issues that otherwise could have arisen.

Plan and prepare for testing

Finally, make sure that the proper tasks are in place in your online project management software schedule to fully handle the project testing work. And by this I mean customer preparation of test scenarios and cases, customer preparation for user acceptance testing (UAT), and then the actually carrying out and support of customer user acceptance testing including approval and signoff. Many customers go into UAT unprepared for what lies ahead. I’m not saying you can get every customer to the point of being testing experts, but you can avoid major project issues and delays during UAT by also planning the proper support and testing assistance from you and your own staff during user acceptance testing. UAT is critical for customer approval and to ensure you’re ready for actual deployment, make sure it’s a critical piece of your project management software schedule as well.

Brad Egeland

Consistent Delivery Wins Customers

BradEgeland — Mon, 28 Nov 2011 19:57:00 GMT

Think about your favorite restaurants. Why do you keep going back to them? Is it because you never know what to expect? Do you consider it to be an adventure every time you go back not knowing for sure how the food is going to taste? I very much doubt it. If one of my favorite restaurants suddenly becomes inconsistent with good service or good food or drastically changes their menu frequently, then I am likely going to take them out of my food rotation. My wife and I did that about a year and a half ago with one of our favorite date night places and we stayed away for a full year. When we went back we found that the food was back to the old high standards, service was once again consistent, and old favorites had returned to the menu list. I’m happy to say it’s back on the list of frequent destinations for us on Saturday nights.

The same holds true with our project and consulting clients. They want to know what they’re getting for their money. They may be a returning client or they may be a new client who heard about you or your company from a colleague. If they’ve experienced consistent project delivery in the past – and I mean good, consistent project delivery – then that’s probably why they’re contacting you again. And if their colleague had good things to say about you from their own engagement experience, then that’s another reason why they are seeking to spend their hard-earned project dollars on you and your project team and organization. And it takes a lot for some organizations to trust and want to spend money on an expensive software or hardware implementation project.

How do we ensure consistent delivery?

How do we ensure consistent delivery from customer to customer or from implementation to implementation for the same customer? How do we show them the same quality of service every time? How do we give them confidence that if we delivered well last time, that we can do it again this time? How do we present ourselves in a way that says, “We’re professionals and we know what we’re doing every time we take on a new project”?

As a basis for continued excellent service to our customers, at a minimum we should be doing these five things for every customer on every project…

Conduct lessons learned

We’ll hit bumps in the road, but if we learn from those mistakes, then we’re less likely to repeat them and we’ll have a better chance of a more successful delivery next time.

Allow proper planning time

Don’t skip the planning. If you do, rework will likely follow. And that usually leads to overrun budgets, missed deadlines, and highly frustrated customers.

Put project planning documents in place as roadmaps

As part of the planning process, don’t skip those planning documents that become roadmaps for good project leadership throughout the rest of the engagement. Documents like the Risk Management Plan, the Communication Plan, and the Test Plan can reap huge rewards as reference tools later in the project and they definitely send a message to your project customer that you are thorough and consistent in your project planning and delivery.

Practice best practices

Don’t forget the regular practices that help your project run smoothly throughout an engagement. Weekly status meetings, weekly status reports, regular internal team meetings, and frequent attention to budget forecasting and analysis are all foundational behaviors and actions that keep your project and team on track for the long haul on the project. Make sure you’re regularly delivering revised project schedules from your online project management software tool. Show them you know how to run a project well.

Plan well for testing

Testing is so critical on the project – I can’t stress this one enough. Prepare your team well for it and prepare your client even better, because it’s really a key task for them as you move toward deployment. Make sure the proper test preparation tasks are included in your web-based project management software schedule. A well-tested solution ensures that your customer will be delivered a package that their end user can truly use.

Summary

There’s no ongoing recipe for success. And the odds say that if you run several projects for the same customer, you’re likely going to deliver a lemon once in awhile. But if you’re consistent in your delivery, you plan well and show them a project management software schedule that really documents consistent project leadership, then those customers will still see the excellence in your project leadership and will remain confident in your ability to deliver the next time, and the next time, and so on. The key to customer confidence is consistency – do that and they’ll keep coming back with their project dollars.

Brad Egeland

Understanding End User Concerns

BradEgeland — Mon, 21 Nov 2011 16:24:00 GMT

Your project customer is truly more than your project sponsor. Certainly, your customer approval begins and ends with the sponsor. However, as an experienced PM you know that a solution delivered to your sponsor’s satisfaction but that does not function as the end user requires is still a fail. Because when those end users go back to the project sponsor and indicate that the solution is unusable or more work needs to be done, the finger pointing will likely start and it will likely be pointing at you.

The key, of course, is to not shut the end user out of the project equation. On the best of projects and with the most knowledge and ‘aware’ of project sponsors, the customer end user group is involved in all aspects of the project. A representative sample is utilized in pre-project requirements preparation. Several are included in the project kickoff session. And, additionally, those same representative end users are often part of the early project planning phases where requirements are further documented and the functional design for the solution is mapped out. Finally, and ideally, end users are what make up the team of customer side players who make up the user acceptance testing (UAT) group.

That’s the ideal scenario. When this happens, you know that the true end user of the solution has been involved in the project throughout and not only do you have a higher likelihood of delivering an useable solution to that end user, you also know that you’re meeting THEIR real need, not some symptom that the project sponsor has indicated as the project at hand.

However, we all know that this scenario is best case and that it is not that common. Many times the end user is shut out of the equation, left to accept whatever is rolled out at the end of the project. And when the $500,000 project is completed and the end user throws up their hands and says that it doesn’t meet their need, your once satisfied customer is now looking to you for answers…and fixes.

In order to avoid this situation, you must do three things…

Understand the organizational role of all the early players

When preparing for the project kickoff meeting, be sure to include all planning tasks in your online project management software schedule and ask the project client for a list of who they plan to have participate in the session. It’s always best to keep the customer list small, as too many participants can cause delays, extend the meeting, and make productive discussions of key project issues nearly impossible. But if you see a complete absence of customer end users, you should definitely raise a flag. You need them in attendance.

Take the project to the end user

During the project – especially during any requirements gathering and planning processes – seek out the end users for discussion. This will likely require that additional tasks be added to your web-based project management software schedule. Have the review high-level requirements to ensure they have a say and that they confirm – at least at a high level – that what they need is what you’re developing.

Run the solution by the end user prior to final deployment

Finally, if they aren’t part of the customer test team, circle back to the end users and have a sample run through the final solution prior to deployment. Ideally they are heavily involved in testing, but that is not always the case due to schedules, availability, etc. But that’s a bad call and it’s critical that the customer end user touches the system prior to deployment. It may involve adding some tasks and costs to the project, but it must happen.

Summary

Several things can get in the way of full end user participation in the project. It could be scheduling issues as indicated in your project management software, it could be costs, it could be ignorance…it could be any one of a number of things. But as the project manager worried about delivering something that satisfies the true needs of the customer, it’s critical that you insist on some end user participation. Take proactive steps to involve a sampling of end users in some planning, testing, and approval at relevant points in the project to ensure you’re rolling out something they can use.

Brad Egeland

Challenges with Going Mobile

Janelle.Abaoag — Fri, 18 Nov 2011 19:03:00 GMT

I recently posted about mobile technology and what it may mean for the future of project management software. I began to build a short list of what I think might change, but then I got thinking a little further. Bottom line, I believe that mobile technology will increase the amount of people that will interact with the project software. That notion of course, is great! The more people that participate in managing schedules, updating tasks or entering time will capture more information and in time lead to improved processes. However, while implementing new software out to more people has plenty of upsides, there will be just as many challenges along the way.

When I refer to mobile technology, I am referring to everyone within an organization or in a particular department having uniform mobile technology hardware and software. This way, they would all be accessing the same information in the same way on the same device.

Therefore, before you even get started…some concerns would include the following:

Determining which device works best for your team. Take into account functionality…where will they be taking it and how easy to use is it?
Set a goal. Why even take the step to go mobile for your team? What would you like to accomplish as a whole by taking this next step?
Train your team. Sure, a lot of us are rather tech savvy and thoroughly enjoy new toys to become familiar with. But you want everyone to be using the software and technology in the same manner. It will take time for everyone to get used to – and we are all a little different.
Separating business from personal fun. With the internet accessible from almost anywhere on mobile devices, how do you ensure that it is being used for the correct purpose? Or what type of restrictions would you apply to your program? Once again, this is probably something you would tailor to your team – but it is definitely worth thinking about.

What other hurdles do you think one should be prepare for?

Janelle Abaoag, Project Insight

Making Responsible Choices for Your Projects

BradEgeland — Tue, 15 Nov 2011 16:29:00 GMT

In project management, as with anything else, best practices are just that….best practices. They are doing the things that seem right and give you the best chance of success on your endeavor. Everyone has a list – I have my own list of what I think some primary best practices are. Those key activities that should methodically happen on each and every project that I run in order to provide consistent delivery to my project customers and at the same time to give my projects the best possible chance of success.

Do we all make wise choices all the time? No. I know I still continue to make some misguided personal and professional decisions from time to time. The key is to look for ways to improve and to notice those good decisions that you do make and take note of their outcome so you can recall that and repeat those same behaviors and decisions when faced again with similar situations.

The responsible choices that we can make on our projects are as endless as the types of projects we manage and the customers we serve. However, I would like to select three specific areas where I’ve been faced with choices in my project management career and I’ve found the path to responsible decision-making – either out of logic and best practices in the case of the 2nd and 3rd example and out of a valuable learning lesson in the 1st example….

Beginning to peer review all deliverables

Out of sheer frustration and the need for some quick corrective action, I learned this one. My team had delivered an error-filled functional design document to the customer that was produced by the business analyst. It wasn’t filled with functional errors – the document was very accurate in terms of meeting the functional requirements of the customer. But it was filled with a few typos and formatting issues that the PDF creator had introduced and no one bothered to review it post-creation. The initial delivery concerned the customer. When the typos were fixed and a different PDF creator was used and the document was delivered once again with issues, the customer became even more concerned because this was the first deliverable on the project. They were seeing repeated quality issues on the very first deliverable….definitely not comforting for them. For the third iteration…yes, I said third…I had everyone on the team review it and thus began my practice of peer reviewing every deliverable for every customer on every project going forward. I build it into the initial schedule from day one and the problem has never repeated itself.

Keeping costs low in the face of anxious customer concerns

On a smaller project a couple of years ago that also had a very tight budget I had a customers who, for some reason or another, thought paying for a project manager on the delivery side was unnecessary. Basically, the project started out with them stating that they didn’t like me. Thankfully, it wasn’t me they didn’t like me – they just didn’t like paying for me. So, from that day forward, I tried to show ‘value’ to them with out costing them too much money. I sent only a critical developer on site for a meeting and some work when I normally would have also traveled to the customer site. Actions like that changed their mind about the PM value and turned things around. We kept costs low because we made responsible choices for the project budget and for the customer whose satisfaction I valued highly.

Stopping your client from making poor but revenue generating decisions

Have you ever had a project customer insist on a course of action that you knew wasn’t right for the project but was definitely right for your organization’s bottom line? I have. It’s tempting to go down the financially beneficial path….you may even have a superior try to push you that way. But the right move – the responsible move – is to help your customer make the right decision for themselves and the project. Because at the end of the project, success will be based more on customer satisfaction than on if you made a little ‘extra’ money for your organization. Trust me, that supervisor – two years later – will judge you more on that overall project success than forgoing the extra $50,000 you could have made for them by letting the customer make a poor short-term decision.

Brad Egeland