Best Practices of Online Project Management

In Part 1 of this two-part series on getting project documents and deliverables right the first time, we began discussing the need to get past the mundane task of creating those upfront planning deliverables on projects that require them (and most should have them, if not all). And yes, you need to build them into your online project management software schedule. In Part 1, we began to look at steps to ensure you provide error free deliverables to the customer…thus keeping customer confidence high because nothing dings customer confidence like receiving documents riddled with errors. They’re thinking…”if this is how their documents look, what will the software look like!” Yikes.

Let’s continue the discussion now in this Part 2…

Peer review everything

It wasn’t until we started incorporating peer reviews for every single deliverable that went to the customer that we started handing over error-free documents. And, of course, those peer reviews must be built into the project management software schedule or they won’t happen. We conducted peer reviews on the BRD (finally), the Functional Design Document, the Test Plan, and every piece of information that went to the customer in written (or electronic) form from that point on and we got it right. I even had the full team review the status reports, weekly status meeting notes, revised project schedule, and issues/risks lists before sending them off to the customer in order to ensure that the customer did not see any more incorrect and unprofessional submissions from our team.

Discuss over a team call

Finally, regroup the team and have a final discussion about the deliverable. Ask tough questions…. Was there anything about the document that didn’t seem quite right, but they didn’t note in their review notes or comments. And check to see if everyone did actually turn in at least some comments. If they didn’t, then they probably gave it the cursory glance described above. After all, everyone on the team is trying to keep up with the tasks assigned to them in the web-based project management software schedule. But you must call them out if it appears that a reviewer failed to review the deliverable. Once the team agrees in person – or over a group call – that the final document is ready to go, then …and only then… go ahead and deliver the document or deliverable. Deliver it with confidence that you’ve put as many eyes on it as is needed and that you are delivering an error-free, confidence-building, customer-satisfying document to the project client.

Summary

On the delivery side we make a lot of assumptions that can be dangerous when we look at things from the customer’s perspective. We take for granted that everyone is doing their job – and doing it well. We assume that when someone turns in work that they’ve proofed it a couple of times and that they care about it as much as we do.

Now, we put ourselves in the role of the paying customer and we tend to not take too much for granted. Instead, we’re actively looking for those errors. We’re looking for the scratches on the new refrigerator we bought (metaphorically speaking), aren’t we? We want our money’s worth. That’s the customer’s perspective. And every time we deliver a product with a dent in it then we have a new dent in our reputation. Don’t let it happen. Take the care to review what you turn over to the customer. You won’t be sorry.

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/.

Customer confidence. Where does it start? When does it go all wrong? And what do we do in between that either keeps it on track or screws it all up? Sometimes we see the train wreck coming and sometimes it sneaks up on us. But since we’re the project managers, we don’t have an excuse…we can’t. Well, we can, but that’s like telling your wife that you didn’t take out the trash because you didn’t have time. Bottom line is…the kitchen still stinks, it was your responsibility to take out the trash so it’s still you fault…even if you were on a multi-million dollar phone call deal. All she cares about is the kitchen stinks because of you. Get it?

So, in the grand scheme of things while running a project, delivering a perfectly formatted, error-free and absolutely grammatically correct Communication Management Plan is probably not at the top of your list, is it? It’s in the web-based project management software schedule as a deliverable, but how much review do you have built in? Enough?  How many of you project management readers out there have heard moaning and groaning from your team members about producing or even proofing plan documents? I know I have…and it’s hard to argue with them when there are other pressing needs on the project. It’s not usually at the top of anyone’s list. It’s easier to glance at it and assume the last guy proofed it well…are you with me so far? It’s not the fun work on the project. And it doesn’t seem – on the surface – the type of work that really adds much value to the end solution…if any. Like when your kids say, “Why do I have to learn this math?  I’ll never use it again.” Sometimes, you have a hard time disagreeing with them, right?

In school I hated to turn anything in misspelled or with handwriting that didn’t look how I wanted it to look. I took me a long time to ever start using pens because I always wanted to be able to erase and correct. Ok, I may have been a little OCD about that. Even with my articles, I run them through spell checkers first – though that doesn’t catch a correctly spelled word that may be out of place or out of context. I try to re-read everything, but sometimes things slip through.

But when we’re turning in documents - that are actually deliverables on a project - to our customer, we need to consider what they’re seeing and what message we’re sending them with the quality of our output. Do we want to come across as educated, professional, and caring of our work? Or do we want to give the customer the impression that we’re sloppy with these early project deliverables? If we’re sloppy with these deliverables, what do you think the customer will assume about the rest of our work as we build a detailed, complex software solution for them. Will they be concerned…possibly anxious? Yes, definitely. And rightly so.

Proof and Test

Extreme care needs to go into our project deliverables. Proof, proof, proof. Test, test, test.  When you hand a deliverable over to the customer – unless it’s understood that this is an early draft – then you’re telling the customer that this is done and the best I can do. It better be correct. It better be accurate and read well. And it better be free of simple typos – there are no excuses for these. The best solution I’ve found is to incorporate a peer review for every piece of documentation that goes to the customer. Build enough review into the project management software schedule – and assign it to everyone on the team – to make the review actually happen. It works, it ensures accountability, and there’s no way that the use of “they’re” instead of “their” will get past five sets of eyes, is there?

Never Assume

I personally made a huge mistake on one project that I was running.  This was before I incorporated the process of peer reviews for all outgoing documentation.  Actually, this example is the reason I began to incorporate the peer reviews.  I had not one, but two business analysts working on one of my software implementation projects for a major airline.  I wrongly assumed they were following my instructions and working together – proofing the documents they were working on and turning error-free work into me to go to the customer.  And, of course, I failed to build enough review time into the online project management software schedule.  Three iterations later on the Business Requirements Document (BRD) and I realized I had a lot of egg on my face and a lot of ground to make up with our customer.  What had been a happy, confident, and satisfied customer before had now turned into a very nervous and frustrated customer just as we were ready to begin developing the actual solution.

In Part 2, we’ll examine the final two steps to ensure those project documents and deliverables are customer-ready for delivery, thus keeping customer confidence high as they receive quality, error-free documents from your project team.

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/.

Project customers can be fickle…no question about it. Many are focused on the project throughout the engagement with a project sponsor who is assigned to this project and it is his life, his work, his every thought 24/7 for the duration. This customer knows exactly what tasks come next in the project management software schedule. And then there are others who are tasked to lead the project on the customer side, but they are only marginally involved….only marginally care. Obviously, these are the ones whose next raise – or even future with the company – isn’t necessarily tied into your success on the project. It’s these people I’m going to focus on in this article. 

This type of customer isn’t lost or avoiding you. They are still around, still participating, and the project is moving forward, but it’s clear that you aren’t always their #1 priority. Maybe you’re not getting great meeting participation from them or they are periodically canceling status calls. Or perhaps they are falling down on their tasks you’ve assigned to them. It hasn’t reached any critical stage that is killing the project, but you’ve seen enough that it is concerning you and you’re struggling to keep them engaged before something gets out of hand. Because let’s face it, you do need them to participate in meetings, decisions, etc. throughout the project.

Below are four key practices to implement that will help keep this type of customer more engaged on the project for the remainder of the effort. 

Change something about the status calls. I’m not saying you need to completely restructure things, but you may need to shake it up a bit. If the customer is participating less or only sporadically or is frequently canceling them, then changing something may get them back. If you don’t see your project client face to face much – or at all – hold video conference calls for the status meeting once per month. Or, if the budget allows, travel to their site periodically for an onsite status meeting. Anything you can do to change the overly familiar pace will likely help – at least for a while.

Create a closed Facebook group for the project. Another move to add some new feature to the project is to create a closed Facebook group for the project. Call it a collaboration step because it’s clear you aren’t getting a lot of collaboration from them at the moment. Encourage your team and your customer to check the group and post to the group daily or several times a week on how things are going on their assigned tasks. I’ve done this on several projects so far with surprisingly favorable results.

Create a ‘customer section’ of the status report. On nearly every project I’ve ever led, the status report has been my sole responsibility to create, deliver, and lead the status call from. But if your project customer is participating less and less, create a section of the report that requires their input – the customer status section. Don’t just ask them to discuss it during the meeting, have them send you the text for the report in advance…that way they’re more apt to attend the call so they can explain what they’ve provided in the report and explain where things stand on the tasks they’ve been assigned in the web-based project management software schedule. Be sure to ask questions about it – keep them on their toes so they know they’ll need to be available to discuss at each meeting.

Hold lessons learned sessions regularly. Finally, do something that I’ve found to be a good move anyway – hold lessons learned-type sessions throughout the engagement.  Maybe monthly, maybe after each deliverable. By scheduling ‘participation’ meetings like this that are obviously geared toward better performance on the project, you’re more likely to increase customer participation. It’s worked for me, for the most part, and the bonus is that what you get out of those meetings will actually help you on the current project, not just your next project.

Summary

The bottom line is we sometimes need to mix it up. It doesn’t mean you have to throw more work their way or micro manage them to get them to participate. But you may just need to make the mundane less mundane. It’s not just about reviewing the online project management software schedule. It’s about collaboration…participation. Change is good…change gets noticed. And if change helps for a while but you see them start to fall back into the same pattern again, then implement a little more change.

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/.

This is an interesting concept that may be intrinsic to some or all of us…or maybe not. But I came across it by accident the other day and thought it might make for good discussion. Let me first set up the background…

My wife is a professional photographer – probably the best you’ve never heard of because she’s not actually seeking clients at the moment…too busy right now with our small children which we have a few of…and that’s a happy place for both of us. I was sitting in my wife’s office working on my stuff while she was working on her stuff. At the moment she was watching an online class on editorial photography through Creative Live / Ustream hosted by Jasmine Star, a professional photographer from California who was discussing a fellow photographer’s revelation of having a bigger vision of what he really wanted to be doing. He was shooting t-ball baseball games and it was driving him crazy. He was bored, lacked any creative motivation, and it was showing in his work. What he really wanted to do was shoot the World Series. Then it hit him – he needed to be shooting those t-ball games like he was shooting the World Series…and his outlook - as well as his output – improved drastically. In fact, a few years later he actually DID shoot the World Series. And Ms.Star applied the same concept to her wedding photography – she was shooting basement weddings and really wanted to be shooting Martha Stewart weddings.  Eventually she was, but not before she came to the same revelation.

The boring trap

This leads me to my concept for this article. As project managers, we sometimes get that small boring project that isn’t much different than our last small boring project. In fact, for some of us out there, that may be how ALL of our project assignments go. We get bored, we go through the motions, we get frustrated, and we think it’s always going to be that way. So why bother with perfection? Why bother with creativity? Why go the extra mile? Why try to be overly visible with our projects…and will it even help?

Have a big vision

Well, it may help and it may not…but if you do nothing, then nothing will definitely happen. That’s the key to the title…we need to try as hard as possible to treat every project like we’re building the Taj Mahal. Every project should be treated like it’s the most important thing we are doing for the company and for our careers. And we certainly need to treat every customer like they are our most important project customer to date. Let it show in your online project management software schedule through the detailed tasks and the way you revise and distribute it. Let it show in the detail and consistency in your project status report. Let it show in the way you engage the customer and lead the project status meetings. Always use best practices, look for ways to manage creatively, and look for ways to garner new business on each engagement. Try not to just tell the customer what they need – try to show the customer something that they don’t know they want. The result will be a happy project client, change orders that add revenue to the project budget and tasks to the web-based project management software schedule, and smiles to the faces of your executive management team. Eventually you will be managing larger projects, more important project customers, and much larger project management software schedules. 

Summary

Manage all of your projects like they are the most important projects in your company’s project portfolio. Don’t just go through the motions…be creative. Always keep your project clients best interests at heart. If you value your career as a project manager and truly want to make a difference, then you won’t regret it.

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/.

No project manager ever became successful by turning a blind eye to unplanned work. No project was ever brought in on budget by allowing the project team and customer to run amok with development work that fell outside the scope of the original project statement of work and documented requirements. It just doesn’t happen. 

At some point the project manager decides if they are going to be a push over and allow the customer to bend and shape the course of the work on the project by continually requesting tweaks and freebies and add-ons for no additional costs or if they are going to draw that line in the sand and say ‘no more.’ It just has to happen. And I understand it’s hard to say no the project customer, but it has to be done because allowing unplanned and undocumented changes to scope to happen is seriously bad for the project and for the engagement’s chances for overall success.

The project manager must act as the gatekeeper between what the project team has been tasked to do and what they are being asked to do. Those two things may start out being the same, but on nearly every project since the beginning of time they have ended up being different. Indeed, the project manager must recognize these 'extra' requests for what they…dangerous unplanned scope changes that are adding up along the way. It is critical that any changes to scope are well documented and that work only proceeds on items that fall outside of the agreed upon scope once they have been documented as scope changes or new requirements and it has been identified exactly how the project budget and hours are going to be affected by these proposed changes.

Basically, there are three key steps in the process that need to happen…

#1 - Identifying that something is out of scope. The process starts when the customer makes a request that you think is outside the agreed upon scope of the project. Your team may help you manage scope, but as the ultimate gatekeeper it’s the project manager’s responsibility to raise the red flag when it seems that work is being requested that is outside the documented project scope. No one has more to lose – in terms of reputation – than the project manager by letting the project go out of control. Out of scope changes, made without the benefit of a change order, can have disastrous affects on the project budget and timeline.

#2 - Documenting the new or changed requirement(s). Once the project manager or one of his team members has identified the potential change – the first step should be to give the customer a heads-up that the work being discussed may fall outside of the scope of the project.  It never hurts to let the customer know this as far in advance as possible. The last thing you want to do is surprise the customer with a change order that they are not expecting…customers like to be informed. The next step is to discuss the change in detail with the entire team and document what work will need to be done. From that, the project manager can put together a formal change order including a price that can then be presented to the customer for review and approval. Of course, the online project management software schedule will have to be revised as well to show the affect of the proposed changes to the project schedule and tasks. 

#3 – Getting approval and proceeding with the change request. Once your team has agreed on the change order effort, tasks, and estimate and you have it formally documented in the form of a change order, it’s time to take it to the customer for formal approval. There’s no guarantee that you’ll get agreement on the first pass and you may even have to make more changes to your project plan through the web-based project management software tool. You also may need to negotiate depending on the size of the change order you are presenting to the customer. The key is to tweak the change order to get the change accurately documented so that you can get a formal signoff with the customer – which serves to essentially create a new/revised baseline for the project in your project management software schedule and a new budget baseline to manage the project costs against.

Final thought

When presented right, with solid documentation and with a forward-thinking rather than defensive or aggressive attitude, the change order is generally accepted as progress on the project and the project manager becomes a change agent. You will have pleased your client by proceeding with the requested new work and you will have pleased your senior management by increasing the revenue on the project with the change order effort. By noticing out of scope issues and handling them properly, it can definitely be a win-win situation for everyone.

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/.

Wow…ever had one of those projects where you wish the customer was invisible? Where you wish they would just step aside and let you and your team get to the business of running the project and implementing their solution. No floating requirements, no questions and constant oversight….just smooth sailing till deployment. It could be glorious. 

It would more likely be disastrous though wouldn’t it? Think about it...yes it would be nice to not have the customer meddling in your work. It would be nice if they’d stop asking for changes or tweaking requirements so you could make unimpeded forward progress.  But without the customer interacting on the project you wouldn’t be made aware of those needed changes and you’d end up delivering a final solution that misses the mark.

Here’s the concern – you still have to meet your customer’s expectations to get a successful implementation. You still have to satisfy requirements. You still have to deliver a product to the customer’s end users that they can use. Even if the customer chooses not to participate – not to be an ongoing part of the team and have any say in what’s going on - if you deliver an unusable end solution, then you’ve still failed. Ouch.

If you’re the project manager and you find yourself in this situation where the customer is not participating – not taking any active role or interest in the project…be concerned…be very concerned. If this really starts to play out for you on your project, then there are a few things you’re going to need to do to cover yourself, your team, and your organization as you proceed on the project. Let’s examine these because they are probably your best hope to either salvage the project or at least save your skin if things go horribly wrong….

Contact the client CEO

If you and your team need things from the customer that you’re just not getting because they aren’t participating, then you’re going to have to go higher up and that may mean contacting the CEO of the customer organization. If they’re still spending money on the project but just not participating, then it’s likely that their CEO doesn’t know that they’re throwing money at a project that may have gone off track due to client-side non-compliance. Pull in their senior management – beg them to be on the next status call. Be loud so you can start getting some customer involvement.  If you don’t shout it from the rooftops, the blame could still come back to you.

Document everything

If your customer isn’t participating, then you need to document that. And even better, you need to keep documenting everything.  Save every iteration of every schedule you produce from your project management software scheduling tool. Document everything that is happening along the way. Every missed meeting by the customer, every assumption that you had to make with no input from the customer, every place where you needed customer interaction but didn’t get it, and every time you delivered something but received no feedback…document it.

Never stop throwing status their way

No matter how uncooperative or non-participatory they are, never stop providing them with ongoing weekly status reports, revised project schedules from your web-based project management software, and project financial information. Continue to give them everything that was agreed to at kickoff time. And continue to hold weekly status meetings even if it’s just attended by you and your project team members.

Halt the project

When all else fails and you feel that too much on the project is suffering because the customer isn’t participating, then stop work.  Document the stoppage in your online project management software schedule. It may draw them out of the woodwork. At the very least, it will keep you from continuing down a bad path making assumptions you aren’t comfortable with and decisions that you can’t confirm with the customer.

Summary

It’s not likely that a project that is headed in this direction is going to end successfully. There’s too much at stake and too much of a chance that the project could end poorly if the customer isn’t participating at all…and you’re the one who could receive all the blame. Do what you can to get them involved. If that doesn’t work, document everything you can. And if that doesn’t work and it’s going poorly, then stop working on the project. Document and communicate to protect yourself, your team, and your organization.

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/.

Lessons learned sessions can be – should be – a vital part of every project life cycle and every organization’s project management methodology.  Sadly, as I indicated in the first part of this two-part article series, 57% of survey responders to my June 2010 PM survey on “Managing the Project” indicated that they conducted lessons learned sessions either never or less than 10% of the time.  Think of all the valuable information PMs and their colleagues could be taking forward to future projects if it were being formally captured and shared in those organizations.  The reality of it is, many companies aren’t pushing for it – possibly due to time and budget constraints – and project managers themselves may not be educated enough in the process or see the real need to incorporate it into their web-based project management software schedule.  Whatever the reason, it is good cause for discussion and it highlighted the need for this type of article series.

In Part 1 of this two part series on successful lessons learned processes, we looked at the first two of five key ingredients to the process.  These were: planning for lessons learned by properly incorporating it into the online project management software schedule and making it an ongoing project lifecycle effort by conducting lessons learned throughout the project. 

In this Part 2, we’ll discuss the final three key ingredients: the preparation for the lessons learned session or sessions, the act of actually conducting the session, and what to do with what comes out of the lessons learned session.

Prepare for the session(s)

As deployment time nears, remind everyone of the upcoming lessons learned session and finalize a date, time, and place for the meeting or meetings.  Ideally, this has been seen as a placeholder in the project management software schedule for most or all the project.  Distribute what you’ve collected throughout the project as a starting point and encourage the rest of the team members and the customer to be proactively working on their lists to ensure the most productive session possible.  Reminding everyone of the need for this session and scheduling it early also helps ensure that attendance and participation will be high – you need to be sure you have secured team members’ availability before you lose them to other projects.

Conduct the learning process

Likely you can perform the lessons learned session in one meeting – especially if people come somewhat prepared.  The project manager needs to act as the primary lead and facilitator of this meeting.  Things to remember when leading lessons learned discussions:

• Be positive
• Do not place blame
• Focus on successes as well as failures
• Indicate which strategies contributed to success
• Indicate which improvement strategies would have the greatest impact

It is also the project manager’s responsibility to be the primary documenter of information that comes out of these discussions.  Preferably, a formal template should be prepared or obtained to ensure that information is captured in an orderly and organized format.

Disseminate the results

Finally, within a few days of the actually session, all information discussed and documented during the meeting should be distributed to all members for final review and comments.  It’s critical that the project manager get final concurrence to ensure that all information has been accurately recorded.  Once approved by all, a formal version of the lessons learned findings should be distributed to all project team members and to whatever central knowledgebase your company uses for capturing formal lessons learned data from engagements.

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/.

Lessons learned…ideally we all perform them at the end of our project and document what we did right and what went wrong. We never again repeat the bad stuff and always manage to incorporate the good stuff into every project we manage from here on out. Sound familiar?  Yeah, sure. One survey that I personally conducted of project managers and other project professionals indicated that lessons learned were being performed 0-10% of the time by 57% of the survey responders. Only 34% were actually performing lessons learned sessions with any semblance of regularity…and I’m assuming they were being a bit generous to themselves.

On a more positive note, I’ve received literally hundreds of requests for a lessons learned template that I’ve put on my site so there must be a lot of project managers out there who are at least intending to start performing these sessions with some regularity. That’s good news. It’s one of those things that all project managers know they should do, but often overlook. Usually, the project ends and the project manager and team members need to quickly disperse and move on to other projects. Making the time and effort to go over the pluses and minuses on the project may not even be an option and getting the support of your senior management to all for the budget to do so – even though it’s a good idea – may be difficult. If it wasn’t part of your online project management software schedule from the outset, it may be next to impossible to justify it at the end of the project – and even if it was, it may have been sacrificed to ensure meeting the project budget. Sound familiar?

In this first part of a two-part series, I’d like to look at the first two of five ingredients to a successful lessons learned process. Actually, the first step in conducting a productive and meaningful lessons learned session is accepting the fact that it is useful. If you can’t get to that point, there’s no use in reading any further. If you can, then read on and let’s look at these in detail….and hopefully learn…

Plan for it

Since the first step in conducting a productive and meaningful lessons learned session at the end of the project is to first accept that it is useful, you must also then plan for it. And by plan for it I mean put it in your web-based project management software schedule. Put a placeholder in the project management software schedule sometime after deployment – maybe a week or two after rollout of the final solution – and be sure to include the prep and meeting tasks necessary to conduct the lessons learned session or sessions. Include the resources and the necessary effort/time so that you ensure your resources are booked for it on the project and so that you’ll be able to regroup them for this effort when the time comes. This may take some negotiation with department managers and your senior management because they may not see this effort and expenditure as a necessary part of the project. You may have to sell them on it.

Consider it as a full project lifecycle process

Why wait till the end of the project to share ideas on what’s working and what’s failing? Why not learn along the way and get some benefit on the current project? Ideally, the lessons learned effort would not just be an end-of-the-project task. Keeping an on-going list of lessons learned during the project will help you, your team, and the customer to be even better prepared for a more meaningful and productive lessons learned session at the end of the engagement. You’ll have a much better knowledge base to move forward with if you diligently document those lessons learned during the project for discussion during that final session. And if just casually keeping a list isn’t enough, consider scheduling lessons learned after each key milestone or deliverable. This will allow you to learn from your performance on the most recent tasks and take that education into the work you’ll be performing on the next key deliverable.

In Part 2 of this two-part series, we’ll discuss the next three ingredients: the preparation for the lessons learned session or sessions, the act of actually conducting the session, and what to do with what comes out of the lessons learned session.

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/.

Wouldn’t it be great if we knew that proper upfront planning meant we would never miss a deadline or milestone on our project? If practicing best practices meant you never strayed off schedule. If you did everything right…then nothing could go wrong because you would be in total control. Is that the way it works? It would be nice…but that’s definitely not the case, is it?

You may have what you believe to be an excellent process for schedule control, and team members are working well together. But in spite of that, you simply don’t meet phase milestones, and some projects are constantly in danger of being completed way off schedule. Why???  You’ve thoroughly mapped the project out using your web-based project management software tool of choice and are doing your best to hold everyone accountable to their assignments…so why the missed deadlines?

In cases like this, you may be perplexed as to why this is happening, but from the customer standpoint they are feeling more and more uncomfortable with how things are going. Excuses, unknowns, repeatedly missed milestones….they all lead to significant reductions in customer satisfaction and confidence. If these project troubles are catching you by surprise then that translates to your customer as poor project management – no matter how detailed your online project management software schedule is. If it appears that you’ve lost control of the project, then your customer will have no confidence in your ability to manage the engagement.

From my experience, when missed milestones start to become a real problem on the project – usually indicated by missing more than two milestones (whether you’re missing the deadlines by two weeks or two months, it doesn’t matter) it is often due to one or more of the following three reasons. Examining these key possibilities in detail can help get to the root of the problem and get the project team back on track toward on time delivery of critical project tasks.

Your project resources are overloaded by other tasks

Check with your resources – are they overloaded on other projects they’re working on or possibly in the departments they are being borrowed from? Are they getting direction from a supervisor to prioritize their work elsewhere? If that’s what’s happening then you have two things that need to be addressed:

• Communication.  They should have let their project leader (you) know that they were overloaded.  Failure to do so put their performance and your project in jeopardy and that is bad.
• Negotiation. You’ll need to negotiate either with their other PMs or their supervisor for their time if they are experiencing priority conflicts.

You need more resources on your project

Usually throwing more resources at the problem isn’t the correct action to take – it can completely take down a project budget-wise.  Building more resources into your project management software schedule may sound like a nice luxury, but they all come at a price.  That said, there are those rare cases where a project actually does need more resources than are currently being applied.  Analyze the situation thoroughly and ensure that this is actually the case for your project before requesting and bringing on more resources.  The next step, of course, will be to fight the battle of getting more funding from either the customer or your own organization – and usually both paths will offer a decent amount of resistance.

You are being subjected to  unreasonable milestone deadlines

The project schedule was probably drafted by sales or an account manager and then handed off to you when the project was assigned.  It was then molded into the very detailed schedule that you are now managing the project against.  There may have been some unreasonable milestones that either were overlooked, or were just not changeable.  You and your team knew they were unreasonable, but the milestones were mandated by something beyond your control – possibly the customer, an industry requirement, or senior management. Sometimes change orders, pressure from above, or misunderstood requirements can leave you with a project schedule that is just not possible to achieve.  And if it’s not adjusted, then the project is going to move further and further off track.

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/.

We often talk about generations or groups of people or skills sets in terms of the next wave. We know now that mobile technology is a must. A social presence, though still hard to quantify in terms of cost and benefit, is critical for every business. If you don’t have one or aren’t using it wisely, you’re already behind. And cloud computing…don’t get me started. While it’s really just doing everything via the internet (apps, storage, etc.) it still messes with people’s minds and it seems to be a mystery to many…including high-powered CEOs. 

So what about project managers? Are the best practices today the same best practices that project managers will need to be following in the future? Will project management be the same 10 years from now as it is today? We create web-based project management software schedules now, but what will we be doing in the year 2020? What advances might we see? We expectations will change? Will there even be a project management discipline many years down the road and will it be online project management software we turn to or something entirely different? And will that matter?

These are legitimate questions. In fact, I’ve been asked nearly every one of these questions in some form or another at some time or another by at least one reader in the last 2-3 years. Project management of the future….where is it going and how much will it change?

The basics

I think there are some things about how we run our projects that just simply won’t change. How we do those things and the tools we use to get there may change – may even change drastically – but the main concept likely won’t change….at least from my perception. Things that I don’t see changing are the basics that need to be part of every project engagement: the kickoff meeting, the project status report, regular project status calls, team meetings, risk management, issues lists and risks lists, change order management, etc. etc. We’ll still create test plans, we’ll still perform user acceptance testing, and we’ll still deploy systems through a hopefully well-planned process. The basics won’t change. So what will change?

How they happen

What I see as potentials for change are these:

Project Management Offices (PMOs). Will we need these 10-20 years from now? I’ve seen them fail as often as they succeed. If they continue to exist, what will their structure be like? I think they serve a purpose - when correctly assembled and executed - but too many lack strong leadership and a good methodology which ultimately lead to them either failing or being irrelevant in the organization.

Project management vs. engagement management. As we are all asked to do more with less, I think we’ll see a much bigger movement toward engagement management vs. just project management. Gone will be the PM’s focus on daily project activities and running the project with project management software and excel spreadsheets. Yes, tools will be more detailed, but the focus of the PM will be broader – they will (or at least they should be allowed to) become much more of an engagement manager. Get PM involved very early on – allow them to be part of the deal closing, not just the project execution. Do this in order to properly set customer expectations, do this to get the best estimate of work and money and tasks possible, do this to have the best understanding of the resources needed to get the job done, and do this to get the project off and running with it’s best chance of success possible once the deal has been closed.

Call for input

What’s your take? What do you think will change in project management in the next few years and what do you think will just stay the same. We all know the software that we now use to manage projects is evolving – there’s no question about that. Where there use to be 3-4 players in the project management software marketplace there are now hundreds. Think bigger…what practices will change? What will the infrastructure of the PM organization need to be like in order to be successful?

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/.

In Part 1 of this two-part series we examined the first three of five common challenges for the project manager and his project team members. We looked at a constant emphasis on function where it can sometimes be difficult to get the team members to focus on the project rather than their own discipline or department since that’s where their paycheck comes from. 

We also examined responsibility vs. authority – the never-ending problem of the amount of responsibility that has been thrust upon the project manager and team vs. the authority they actually have (perceived or real) to make things happen. The PM can create a very detailed project management software schedule to manage from and assign tasks, but if he lacks authority to make things happen or if the project team members lack authority to get tasks done, it may be all for not.  Sometimes responsibility and authority just don’t match up well.

And finally, we also looked at being faced with unrealistic targets in terms of project goals, deadlines, budgets, etc.  These are often thrust on the team with little to no input from those that will need to get the work done and know best what it will take to make that happen…the team. No amount of tweaking your web-based project management software schedule will make it work out in the end if it’s truly an unrealistic target.

Now let’s examine my final two common challenges: the dual responsibility trap and the conflict of certainty and uncertainty.

The dual responsibility trap

Depending on the type of organization, many project managers are asked to wear two hats.They must perform their job duties while acting as a project manager. This situation may present additional challenges for the project manager.

At the center of this dilemma is the issue of allegiance. Imagine for a moment that you’re facing a critical decision. Unfortunately, what’s best for the project will negatively impact your work group but what benefits your work group will hurt your project and may mean you miss a critical deadline in your online project management software schedule. What’s the right decision? What do you do? If you make the decision that benefits your work group, you risk being viewed as a poor project manager. If you choose the course of action that benefits the project, you may incur the wrath of your peers and/or departmental management. It’s a tough spot - and you can almost bank on being in it, possibly often. A more fundamental problem of the dual responsibility trap is figuring out how to divide your time and attention between the two roles. How much should you allocate to each? How long can you try to satisfy both before you realize you’re working most nights and weekends?

Finally, a third issue often surfaces in the form of the two boss syndrome. The project manager reports to his or her functional supervisor and to the person who manages the project management function in the organization. Again, this is a difficult situation for most project managers.

The conflict of certainty and uncertainty

Many misunderstandings and disconnects between project managers and organizational management can be traced to the fundamental conflict between the certainty that management requires to properly run the business and the inherent uncertainty of project work. Cost and schedule estimating provides us with an excellent example.

Consider this… you’re just beginning a project and - as often the case – you have limited information on this project and there’s a significant degree of uncertainty. In a situation such as this, project management practice suggests that you would be well advised to use ranges of values when providing estimates on cost and schedule. The size of your range would reflect a level of accuracy consistent with the extent of your knowledge and the amount of uncertainty. But organizational management isn’t often accepting of a large range of an estimate any more than they want to see you padding the estimate for comfort’s sake or safety’s sake.  The conflict and dilemma of certainty and uncertainty can weigh heavy for the project manager and his team.

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/.

Managing projects in your organization is going to be a challenge. No one ever said that project management is an easy profession. You can expect to face a number of challenges as you take on the responsibility of managing projects for your company and for your customers. Whatever the specifics of your particular situation, however, many of the challenges you’ll face are faced by most project managers - so you’re not alone. I’ve broken this down to five common challenges and I’d like to discuss the first three of those five in this Part 1:

Constant emphasis on function

If you’re managing a project in a functionally oriented organization, one of the more difficult challenges that you’ll face is getting team members to overcome their inherent tendency to think and act in terms of optimizing their own discipline, technical field, or department. It’s important to recognize that this phenomenon is fueled by three powerful influences. First, by definition, projects are temporary, but functions live on. In other words, a person often considers his or her work group to be home; the project is just a passing state of existence - tasks in a web-based project management software schedule that must be completed, but have no bearing on his ongoing responsibilities in his main workgroup. Second, unless contemplating a formal career change to project management, a person considers his or her discipline or area of expertise as the work focus. This means that her will likely be committed to ensuring the well being of that area. This strong loyalty could, for example, give rise to counterproductive situations, such as team members using your project funds to advance their discipline - perhaps in excess of what customer requirements dictate. Finally, there’s the power of the paycheck. Simply stated, most people tend to pledge allegiance to the source of their paycheck. For most people in most organizations, that’s their work group or functional department, not the project manager and the project.

Responsibility vs. authority

Firmly embedded in project management folklore is this one: the responsibility you’ve been given is not in line with the authority you believe you need to accomplish the mission. The size of the gap between responsibility and authority will partially depend upon the structure of your organization. If you’re in a purely functional organization - and in many cases, a matrix organization - you should not expect to be given a lot of formal authority. The gap between responsibility and authority will be quite wide. To compensate for your perceived lack of formal authority, you’ll have to rely upon expert power (respect you can garner through superior knowledge or capability) or referent power (often accessed by practicing an excellent leadership style). You’ll also need to rely heavily upon your ability to influence and persuade. So, the burden to overcome can be great…again, no one said this job was easy.

Unrealistic targets

Sound project management practice suggests that project goals (cost, schedule, quality, and functionality) should be determined through a systematic process of understanding customer needs, identifying the best solution, and formal planning. Throughout this process, realistic assumptions about resource availability, quality of work and materials, and work process should be used. This approach yields a credible estimation of what is reasonably achievable. If this estimation does not meet business goals, then a systematic risk vs. return process should be pursued until it can be verified whether or not the targets can be met within a given level of elevated risk. That’s the process that should be followed.

Unfortunately, we live in a real world. Targets are far too often based on desire or a vague sense of what should be achievable, rather than driven by calculated business needs. In even more unfortunate circumstances, targets are developed before it’s even known what the project entails - often built into the project management software schedule by someone in sales before the project manager ever gets assigned. Yes, a clear case of putting the cart before the horse.  In either case, the result is that impatience - rather than a rational process - drives the selection of the targets. From that point on, a desperate struggle begins, as the team tries to force the project to fit within the boundaries that have been drawn. This practice puts project managers in a very difficult position, as it often sets them up for certain failure and severely undermines the planning process. Indeed, this practice is one of the biggest challenges faced by project managers today.

In Part 2 we’ll look at two final common challenges for project managers and their project team members: the problem of dual responsibility and the challenge of certainty vs. uncertainty.

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/.

Project managers strive for creating and maintaining a smooth running project from beginning to end.  In order to have any chance at that, there are some steps – or prerequisites, as I like to refer to them – that must be taken care of by the project manager to setup an effective project organization from the outset.  Following these prerequisites will at least give your project its best chance of having a solid structure and backing and thus increase its chances for success in the long run.  Let’s examine my list of ten in more detail..,

The project manager must know the project goals. This knowledge will help the project manager determine how to best arrange his resources on the project and how best to plan for them in his online project management software scheduling tool.

The project manager must know all the players. This knowledge will help the project manager to determine who will support him and the project team directly and who will provide ad hoc support for the engagement.

The project manager must understand the political climate. Although the team may be temporary, the project may be around for a long time.  Knowing the political climate in the delivery organization – and the project client organization – is key to planning a successful project.

The project manager must receive preliminary concurrence on the project organization. The project manager needs this concurrence from all the major players on the project – senior management, the customer, all stakeholders, etc. – to help ensure proper buy-in, backing and support of the project team.  This is important when resource issues arise, roadblocks get in the way, and problems come up that can halt or stall the project.

The project manager must determine the appropriate span of control. This means determining how many people he can effectively manage before establishing an additional layer of management like appointing team leaders.  Of course this isn’t necessary for small teams or short-term projects.  However, on long-term projects with a large team, this can be critical.  A project with a team of this size will be easier to manage with the right web-based project management software handling all of the resource leveling needs of the engagement. 

The project manager must publish the organization chart as early as possible. This action will clarify roles early and reduce the opportunity for conflict. It will also make assigning responsibilities in the project management software easier. 

The project manager must consider how much autonomy to grant people on the project. This will depend on how much control the project manager wants and needs to maintain and it will also depend on the individual team members’ ability to govern and manage themselves and make key project-related decisions. If he wants tight control, he will limit the autonomy he grants to project participants. But the best scenario is a project team that does not need time-consuming micro management from the project manager allowing him the freedom to perform other project management responsibilities.

The project manager must consider issues of authority, responsibility, and accountability. How much authority will the project manager have and how much can he grant? How much responsibility can he relinquish and still be accountable for the results?  Some of this may depend on the requirements of senior management and requirements of the customer’s organizational structure.

The project manager must consider how to group the functions of the project team. Should he mix them or segregate them? If the latter, how will he encourage information sharing, communication, and teaming?  How will the team best collaborate?  These are key questions to ask when planning how to perform project management functions on the engagement.

The project manager must identify the line and staff functions. The goal of the project will help determine the positions. Line functions contribute directly to the results; these are typically people on the core team. Staff functions do not contribute directly to the results and ordinarily they are not part of the core team. 

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/.

Best practices aren’t always about best project management practices. Sometimes they are just about doing great things for your customers to make them happy. Yes, this might be self-serving in nature because…well…why do we want to make our customer happy? For their own good? Or for our project’s success? I’m thinking it’s mostly for our project’s success. That’s always what it’s been for me anyway. Don’t get me wrong, I like my customer, but I’m primarily interested in bringing home a successful project and that customer satisfaction is one of those key determining success factors. That’s usually my motivation.

If you’re experiencing issues on your engagement, certainly those need addressed. However, if your project is running along rather smoothly and you are simply looking to gain key valuable points with the customer, then try these three things…

Increase weekly touch points

The first thing you can do is increase your weekly touch points with the customer. If they are close, you can ‘drop by’ during the week. If you’re only really having one call – a more formal status call – with the customer, perhaps make it a point to have at least a couple more adhoc calls just to check in and ensure everything is going well.  It can be as simple as calling them after you’ve sent them a revised project schedule from your online project management software tool. Really, it’s all about communication and not just assuming everything is fine. Talk to them more often than you currently do – without over doing it. If you go too far they’ll wonder what’s up. If you do it just right, they’ll appreciate the additional communication.

Customize status reporting

If you’re like me you probably told the customer how you were going to deliver the status report and what was going to be on it – likely based on some standard that your organization and/or PMO has in place. Sound familiar? It may be time to change gears and ask the customer what’s important to them. Maybe they want financial data on the report and it’s not there now. Maybe they would like to see key tasks included that are filtered from your project management software tool. Maybe they don’t want issues and change orders included. Whatever the customer preference is, find that out and do your best to act on it. 

Involve a C-level in your project

Get someone high up interested in the project. Maybe that’s your CEO or maybe it’s a different C-level or high up employee. Have a senior level individual sit in on one or two status calls and introduce themselves and participate on the call. Of course, bring them up to speed first by providing them with a copy of your current project schedule or give them electronic access to it through your web-based project management software. Your customer will appreciate the added visibility for their project within your organization and they will immediately begin to feel like a more important client to your organization. 

Summary

The bottom line is that you can do all these things if your customer is upset and the project is struggling. Yes, they will help. But if you proactively do these things while your project is going well then they will serve to raise your current customer satisfaction and keep everyone operating at a high level on the project. Checking project health in these areas on healthy project keeps you, your team, and the project in general from just going through the motions and welcomes proactive action on your part.

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/.

You’ve all heard that you have to be loud to get your way, right? You know the phrase…the squeaky wheel gets the grease. It basically means that in the office place, the person who is the loudest or complains the most gets the attention, the focus, the concessions, the resources…whatever it is they’re looking for. Whine and it shall be thine.

Personally, I've never been good at being the squeaky wheel because I don't make noise like that. It’s not my way, and while I’m sure it’s probably hurt my career at some point, it’s probably also helped it. One thing I have discovered, though, is that I can make my project visible to senior management and others in the organization through my own normal daily and routine project management actions and wise use of my chosen project management software tools. By doing so, I can ensure that senior management knows who I am and what my project is about. Why is this a good thing, you ask? Three reasons…

If senior management knows your project, they have no excuse. Your company leadership individuals are busy. If they aren’t your PMO director and your project isn’t directly tied to their revenue stream, their bonus, or whatever the CEO wants them to do next, then your project isn’t on their radar. If you put it on their radar through your own actions using your web-based project management software solution, then they have no excuse. If an issue arises, they are already aware of your project and are up to speed…because you made sure of that.

If senior management knows you, it’s harder to say no. It’s hard to flush a fish that you already named. It’s hard not to buy fund-raising candy bars from your own family members. And it’s hard for your executive management to ignore your project calls for help if they have already been familiarized with you. Sort of like turning your back on a workplace ‘friend.’ You just can’t do it easily. You’ve already positioned them to be your ‘champion’ if you have a need…because now they know you.

If senior management knows your client, they feel an obligation. In general, your project clients are important to your senior management. I say, in general, because account managers land these clients and project managers – like you – lead the implementations for these clients. Your executive management team cares about these clients, generally….and possibly generically….because they mean revenue to the company. But through your actions, they now ‘know’…really know who your project client is and they begin to feel a form of obligation to the client – a responsibility for their satisfaction – because you made it that way.

How did you do it?

So how did you get to the point that your senior leadership went from being indifferent to your projects, unaware of you, and unattached to your project client? I don’t mean to make senior management sound like a bunch of uncaring, soul-less individuals. Not at all…they have their priorities and their own jobs to do and you have yours. But you have wisely taken action to make your priorities encroach on their priorities without being that squeaky wheel and annoying everyone. So how did you do it? Here’s how…I like to call it the three ‘I’s”….

Inform them. Unless you tell your executive management about your project, they won’t know about it, right? So tell them. But I don’t mean go into their office and bore them with the details. Not at all. Just start sending them your project updates from your online project management software tool. Send them your status reports. Send them your resource plans. Send them updates of your budget forecasts and your project schedules. They may wonder why they’re getting them at first, but they’ll have them and sooner or later they’ll review them and become familiar with them. They will probably even thank you – via email, of course – for sending the info to them.

Introduce them. Introduce yourself and your team to them. This may have already happened in a smaller organization where most people know most people. But in larger organizations, that’s not the case and you must take initiative. You don’t have to become buddies, but make a point of getting yourself and your team in front of several company leaders – either by having them sit in on one of your customer meetings or by dragging them into an internal team meeting. It’s likely going to be easier to get them to come to a customer meeting – especially if it’s a significant project milestone.

Invite them. This one overlaps a bit with the previous one, though really it focuses not just on having them on a call with the customer. No, it will be much more effective if you have them actually sit physically in the same room with the customer. Trust me, your customer will be happy that your senior management is engaged – or appears engaged – in the project because they’ll feel more important for it. And now your company leadership knows the client and will feel some sort of obligation to help the project should issues arise.

Takeaway

The bottom line here is, you can figure out ways to get your senior leadership engaged in your projects and daily activities without being the whiny center of attention.  You can get the grease for your project without all of the squeaking.

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/.