Ideally, we keep our project team intact throughout the engagement and ideally everyone works together productively and efficiently and cohesively. And ideally everyone does a great job, has no run-ins with the customer and has the necessary skills to perform all of the project tasks they are assigned to perform. Ideally.


However, it does happen from time to time that we need to bring a new resource to the project. Someone on your team may not be living up to the ‘ideals’ mentioned in the first paragraph above. Or perhaps their skills are now required on a new, very high-profile project or on a project that is performing poorly and needs their help for a period of time to get over whatever issues are currently being encountered. Or perhaps they just got fired from the company. Whatever the issue, if you need to onboard a new resource to your active project, then you need to do it efficiently, strategically, and in a way that will retain customer confidence in your team and your ability to manage them and the project as a whole.


When this is necessary, I generally try to follow the following 5 step process to get the new resource up to speed, onboarded, and productive so as not to experience any hiccups on the project….


Customer alert. So as not to look deceptive to the project client, the first thing I do is alert the customer that a change is going to be taking place. I give them as much information as possible about the situation – in a positive light, of course – and may provide a resume for the incoming resource if it’s relevant…or at least the resource’s experience summary with the company or similar projects. Basically, anything that gives the customer confidence that they aren’t going to experience a drop in service. This is especially necessary if the resource change is being necessitated due to the customer’s own dissatisfaction with the outgoing resource.


Knowledge transfer. Next, I offload as much information as possible to the new resource and call upon the project team to do the same. I provide as much project history and documentation as possible: the statement of work, my presentation materials from the project kickoff meeting, the requirements document, updated project schedules, status reports, budget forecasts (if needed), resource forecasts, etc….anything that can give the resource a good snapshot of where we started and where we are now. As for the rest of the team – I call a team meeting and introduce the resource and ask that they give any relevant information they can think of right there to the new resource AND that they each have a call or meeting within the next week one-on-one with the resource to give them their updates on the project.


Customer introduction. My next step is to conduct a formal introduction of the resource to the customer on the next project status call or face-to-face meeting. They may not be productively working on the project yet – likely they aren’t – but it’s a chance to conduct some friendly banter with the project client and to allow the customer to ask any questions they might have of the new resource.


Status call sit-in. This step may or may not be possible…but I like to have the new resource stay in the ‘shadows’ for a week or two. Obviously this works best if the outgoing resource is still available for 1-2 weeks. That way the resource can see how the meetings are being run, what their involvement expectations are and see exactly where things stand and what appears to be the main areas of interest for the project client.


Productive activity. Finally, I expect the project resource to be fully up to speed and productive on the project within 1-2 weeks. As mentioned, that may be an immediate requirement if the outgoing resource is completely gone and the rest of the team can’t pick up the slack in the interim. But under ideal circumstances, a 1-2 week scenario is what I shoot for.

You can't figure it out. Your project is tanking and nothing you do seems to help. Your team isn't focused, your customer has given you as much slack as they are going to and you know they are about five feet from the Bat Phone ready to call your Commissioner Gordon CEO and ask for your replacement (and quite possibly your head on a platter as well). You're missing deadlines, quality is off, and the budget is through the roof. How you stayed on this long, you just aren't sure. Time to throw in the towel? Maybe even turn in your letter of resignation? Not so fast. Quitters never win. And real winners never quit. And if you are going to go down, at least give it a real fight.


Focus on these five areas – immediately…


What is the #1 priority right now?


Figure out the #1 thing that needs to be taken care of right now and work on it. Don't procrastinate. And if its something someone on the team can do faster or better, delegate. Then move on to #2, then #3, and so on.


So many times we get caught reacting to the loudest shouter or to whatever stops us on our way to complete a task - just like the employee rushing through a grocery store. He's obviously working in something, yet we stop him and need him to show us where the peanut butter is. Does that sound like you when you're working in tasks? Shut the world out and get it done.


What can you accomplish today?


Like above only different. A top priority task is fine. But sometimes a top priority task may take a week or two. Or may only be a half time effort. If so, then also look for something you or a team member can accomplish TODAY. Not just start, but also finish. Sometimes excess issues or problems can make us lose focus on what's important - and right now that's showing forward progress in the midst of chaos.


Revamp the communication system


Many times when projects start to really fall apart you can trace it back to a communication breakdown. Are meetings still consistently happening? What has the attendance been at the last few project meetings? Make the mandatory. Take control as the PM. If key personnel aren't attending or aren't participating and that is causing problems, go to their managers. Get them in those sets or replace them.


Likewise, are you as the project manager communicating effectively and efficiently? If there isn't a communication plan in place, stop and create one and follow it. An example of a good communication plan is available for free download on my site. Use it - you won't be sorry.


Rally the team


Often in bad times, cohesive teams rally together and around their leader. That isn't happening here though, is it? Gather the project team together and map out the issues. It doesn't have to be anything more than a nice spreadsheet with issues, status, assignments and descriptions. But document every single issue so you know you're in control and on top of them. That alone will empower you and your team - and it may delay that call to Commissioner Gordon.


Have the one on one with the customer lead


You know you're stinking up the place. For whatever reason or reasons within and/or outside of your control, it's not going well. You know your customer is aware even if not much has been said. It's time to pick yourself up by your bootstraps, stop avoiding "the discussion" and sit down one on one with your counterpart on the customer side.


Go through the issues, don't pass blame, show accountability and ownership, and layout a roadmap that leads somewhere in the vicinity of success. At least show that it points somewhere in the direction of that light at the end of the tunnel. Your customer will appreciate the ownership and communication and will hopefully acknowledge the fact that you are obviously trying to take steps in the right direction. That alone will delay the call to your CEO. Trust me.


Summary


Sometimes success just isn't going to happen. And sometimes that failure can be epic and career defining. But while you still have a chance to show everyone that you're trying to turn it all around...do so. At least if it all still crashes you can say you did your best to pull it back together.


What about you? Have you had an utterly issue-riddled project that you were able to turn around? How did you do it? What was the outcome?

As my wife continues to force the country genre on this classic rock guy, I actually find some connections with many of the songs and how they relate to life in general and, in some cases, to project management.


Other than the fact that the term "blue jeans" is usually proceeded by the word "them," as in "she looks good in them blue jeans," and of course all of those blue jeans seem to be painted on, or that they seem to have lots of time for conversations with strangers in bars and little regard for continued employment, as in "I may get fired but that's alright, I'm doing what she likes…," I can usually relate to many other concepts and principles presented in the songs.


One Tim McGraw song really hit home for me - "Portland, Maine". First, because I was first made aware of Portland, ME about 15 years ago, and my first thought was that the state was a typo. Then I'm thinking, "Where the heck is that?" I had to go away and research and found out that there actually was a place called Portland, Maine.


Now, let’s bring this back to project management. You know those times when a project customer wants something on a project that no one on your team has ever heard of?


No one has checked out that technology. No one is even sure that what they are asking for is even possible…let alone practical. You're tempted to say, "What are you even talking about?!?" Much like me thinking, "Portland, Maine…I don't know where that is."


What do you do?


You certainly don't want to seem ignorant. Likewise, you don't want to just blatantly agree to go along with or endorse something you don't understand or know much about.


Just like one lie can lead to another and another, soon all you have is a messy house of cards that is bound to fall apart at any moment. The same is true with acting like you understand and can do something that you know little to nothing about.


If you keep going along with it, you will be wrongfully setting customer expectations that you likely cannot fulfill. Believe me, customers would rather you be honest with them and set proper expectations.


So if you find this happening on your project, and you just don't know where Portland, Maine is, then what do you do?


As for me and my teams, these have been our chosen steps…


Ask for More Details


Clearly this article assumes you're lost and need a better understanding. So say so. Tell clients that while their option sounds good, you and your team need more information from them as to why they are pushing for this choice. You need to know how it fits with their business processes.


Go Away and Research


Next, go away and conduct some thorough research. It's a good excuse to broaden your horizons and learn about new technology. Whether or not you end up using it, the effort will still be beneficial.


Meet Internally to See if You Have Enough Understanding


Next, regroup with your team. See if you have enough understanding of both the project and the new technology to make some key decisions about design and next steps. If not, do more research.


Meet Internally to Determine if That's the Best Way to Go


Once you feel comfortable with your level of knowledge on the topic, discuss with the team as to whether this is a good path to a solution. Come up with several options and solutions to present to your project client in the next step.


Present Options to the Client


Finally, go back to the clients with your new-found knowledge. Keep in mind, If you’re going to squash their dreams of using this new technology at this point, you need the knowledge and reasoning to back it up…so be ready.


Summary


Whether you follow these exact steps or develop your own, the bottom line for all of this is that you will have clients that want you to do this or that on the project. If you aren't familiar with something, it's better to say so and do research than to pretend.


Never just say yes to your client without giving it some thought. Once you do, you've set expectations. You better be ready to meet those expectations and be judged against them.

Today I am going to start providing project management tips that I have gathered and endorse. Probably about 25 of them at a time. These are designed to help new, experienced and hopeful project managers be successful in the real world of project management, customer management and project team leadership. If you have any questions or comments - please send them to me via email or fill out my contact form. If you need mentoring or one-on-one learning and discussion, please fill out my mentoring contact form. Thanks! I hope this list and future lists are helpful. Let me know!

• Carefully review requirements before beginning any project - detailed reqs are critical to success 
• Use the project kickoff meeting as expectation setting session - use lots of Q & A to address topics 
• Project success begins and ends with efficient and effective communication - key PM responsibility 
• Don't start work on the engagement until requirements are detailed enough in order to avoid rework
• PMO success begins with buy-in from executive leadership - critical to funding and support 
• More than 50% of projects fail - use repeatable processes to replicate successes 
• Staff the PMO with a strong leader - a PMO director who must focus on managing projects can't lead 
• Involve customer SMEs in requirements definition process - they are ultimate success determiners 
• Customize the status report for what the customer wants - make it relevant to them 
• The customer knows what they want, but it may not be what they need - ask the tough questions early on 
• Peer review all customer deliverable documents - errors cause customer confidence and satisfaction to drop 
• The project team must extract the true client needs through requirements planning 
• Evaluate customer requirements for completeness - detailed requirements are the lifeblood of the project 
• Use a requirements traceability matrix to document requirements and tie them to design elements 
• Project manager's top priority should be the customer and their satisfaction. 
• End user documentation should be specific to the customized solution delivered in order to be useful 
• Recognize problems early on - they're easier and cheaper to solve than big ones discovered later on
• Plan enough internal testing to ensure the project solution error free and ready for UAT
• Build risk reduction strategies into the project plan. Allow schedule time for risk activities. 
• Only 57% of surveyed PMs conduct weekly team meetings - proper prep keeps the customer well informed
• For risk interviews use a risk profile with specific questions that will help stimulate discussions 
• Learn from past project mistakes - keep applying lessons learned to help ensure future success
• Project managers must recognize the difference between minor risks and major risks and prioritize 

The radio is blasting, someone's knocking at the door. I'm looking at my project manager - he's passed out on the floor. I've seen so many things that I've never seen before. Don't know what it is - I don't wanna see no more.


In 1967, an American band formed that would soon come to be known as “Three Dog Night.” And those are slightly altered words from one of their biggest hits...”Momma Told Me Not to Come.” Apparently a band member is singing about going to party and seeing lots of crazy stuff that his mother warned him about if he went.


The origins of strange phrases and terms and how a rock band got it's name


Terminology is a funny thing. We hear something over and over again and we end up never wondering why it's called that or what a certain term means...we may assume everyone knows and we'd look stupid for asking about it. Take this bands name...how did it come about...what the heck does it mean? In 1967, the lead singer's girlfriend suggested the name after reading a magazine article about indigenous Australians, in which it was explained that on cold nights they would customarily sleep in a hole in the ground while embracing a dingo, or wild dog. On colder nights they would sleep with two dogs and, if the night was freezing, it was a "three dog night." Now you know.


Have you ever gone through a process of hearing a term and thinking you've let the project go too far to now ask what it means? You assume that everyone but you must already know what it means so you're afraid to ask it's meaning for fear of looking stupid. That happened – literally, with 10s of thousands of individuals with cloud computing. It became a mainstream tech / IT term and everyone thought that all their colleagues knew exactly what it meant so everyone was afraid to even ask what the heck it really meant. I was lumped in there somewhere, too. So I finally checked into it and while I was close, I wasn't spot on – actually I figured it had to mean more than what it actually meant. It ended up being far less mysterious than I thought. It has been refined a bit from it's more original, broader definition, but in general, cloud computing is defined as “Internet-based computing in which large groups of remote servers are networked so as to allow sharing of data-processing tasks, centralized data storage, and online access to computer services or resources.”


VDI, or Virtual Desktop Infrastructure, is another one that comes to mind. I didn't think too much of it till I was asked to do a white paper for a client about it. Since they were offering a nice large payment for this service, I wanted to make sure I knew what I was talking about. Going in, I was about 85% right about it, but did some quick research to get that to 100% and to the point where I could write a great white paper about it and their diagnostic tools integration with VDI. Don't get me started on “Visual Hacking” though – I've already spent an entire article debunking that as a crazy idea...that one isn't really hacking and it IS stupid.


Conclusion


What am I getting at? The bottom line is this...if you are the project manager running a large, complex technical project, don't make the mistake of assuming that you know everything about this technical solution and understand the terminology. And don't make the mistake of assuming that your entire project team – no matter how technical they are – and your project sponsor and your senior management all understand the technical terminology that is being used on the project. In fact, assume that at least 25% of them are a bit lost on 25% of the technical jargon you may be using. It's a good idea to put together a glossary of terms – maybe as part of the requirements document or an addendum to the statement of work or ongoing status report (and add to it as necessary) that identifies some of the less clear tech terms and defines them. Trust me, you'll be putting lots of minds at ease along the way without making people stand up and admit they don't know something. You'll also be managing the communication portion of the project properly be helping to keep everyone on the same page in terms of understanding and clarity throughout the engagement. And you'll be helping to ensure that good decisions are being made going forward because everyone truly is fully informed.

This article of mine first appeared on CIO.com during the "deflategate" controversy. Brady has moved on to the Buccarneers - but he's still Tom Brady. Consider...

Pardon me if you are a New England Patriots fan. I was once, but I just can’t do it anymore. They are good, but they cheat. And he – and the team – should be justly punished. They were, but a judge somehow saw fit to intervene and undermine the NFL Commissioner’s authority and overturn Brady’s punishment. I’m appalled. It’s crazy.


So lets consider the situation. Brady appealed his punishment to NFL Commissioner Roger Goodell - basically the CEO of the NFL if we are equating this to the business world. Goodell basically said "no, you're still suspended...largely because you tampered with evidence by destroying a cell phone that we asked you to turn over." I realize these aren't exact quotes...just a summary of what happened.


If I cheated in an organization that I worked for, and the CEO was gracious enough to suspend me rather than fire me, I'd take the suspension. The last thing I would do - unless I was actually fired without cause - would be to go over my CEO's authority to a judge to try to get him to let me take over my project again.


Now let’s consider the business world. Let’s consider…what if Tom Brady was a project manager? What are the pros and cons of what he did and what he brings to the table at a high-level? And seriously, what should the final outcome be? Be thinking about how you feel about the situation – setting aside your personal feelings about him or his leader, Bill Belichick, for a moment while you try to consider this objectively.


Pros


Looks for an edge. What Tom Brady did – having the footballs deflated after the weigh-in - to try to gain an edge in the AFC Championship Game over the Indianapolis Colts could be seen as a take-charge action. Like a PM in a tight situation, he considered what might give his project team a slight edge and he took action. He was proactive and he was a quick decision maker. As a project manager on a large, complex project, we need to always be looking for an edge because often with changing customer needs and requests and requirements that are already complex and possibly hard to capture in great detail, we are always under the gun. Any edge helps. Apparently Tom Brady understands that well.


Leadership. There is no question Brady has the leadership skills that someone like a project manager needs to successful engage his teammates on a large-scale, complex project. He’s proven it several times – four to be exact – on the NFL’s largest stage…the Super Bowl.


Cons


Honesty. While his teammates may follow him off a cliff because of his leadership skills and ability to find and exploit any edge possible, his honesty has taken a huge hit a few times and over time that will erode a leader’s image – even within his own team. His legacy may, unfortunately, be deflatgate over four or more Super Bowl rings.


Integrity. See honesty…ditto.


Makes his own rules. Some may see this as a plus. I do not. We should respect those in authority over us. While he may respect his coach, Bill Belichick, he doesn’t seem to respect the rules and policies of the NFL and that’s critical. If you make your own rules, then you shouldn’t be allowed to play.


Conclusion / call for input


So, I think you know my conclusion. If Tom Brady was a project manager in my organization, I’d have to fire him. He broke rules, allegedly lied about it, and then allegedly destroyed evidence. He would have to be gone.


What’s your take? Would you want him in your organization? If you were the CEO that he lied to, could you keep him onboard knowing that everyone knew he lied? Knowing your project customers – your biggest and best clients – know that he lied. Could you continue with him in your organization?

When we are working in professional environments we should be acting professionally and treating others professionally. I always believe it is best to live by the motto or golden rule of treating others the way you want them to treat you. It's worked well for me for 30 years of professional work as an employee, team member, manager, project manager, developer, consultant, speaker and author. Most of that time has been spent as a manager and project manager leading skilled teams of dedicated professionals and working closely with other peers in the organizations I am either working directly for as an employee or with as a consultant.


As you can imagine, it is always in my best interest to try to get the best and most productive work out of those who work with me and around me. Another words, cooperation is important. Over time, I've derived these five tips for getting the most from the individuals I work with and manage in order to best serve my organization and my customers. As you read through these five practices, please be considering what has helped you the most when you are trying to get the most efficient and productive work out of those around you.


Practice effective and efficient communication. Good leadership always starts with effective and efficient communication. For project managers, for example, my strong belief is that it is their number one most important responsibility. In fact, I would expand that to cover all managers and leaders of individuals. Failure to properly and accurately communicate is the basis for many failed projects and tasks – sometimes costing organizations millions of dollars in the process. If you're looking to get the most out of those around you, then it will always need to start with good communication. Everyone must be on the same page and focused on the same goals in order to be as productive and efficient as possible.


Recognize and reward. If you want consistently high production and repeatedly good performance from employees and team members, then you need to be ready to recognize the good performances from those team members and staff and reward that behavior. When you're leading a project and the outcome is successful, recognize the team in a company-wide announcement. When an employee or team member goes above and beyond the call of duty on a project or task, recognize that employee or team member publicly. If it directly affected a customer, call that performance out to the customer with public praise. No one wants to work for a manager who always claims success from the work of others. If you want to draw the most from your staff and your team – don't be that kind of manager. Acknowledge individual performances publicly – the payback on such public acknowledgement can be huge in terms of dedication, following and future performance.


Be open and honest with everyone. I am a firm believer in open and honest interaction with our team members, employees, customers and stakeholders. It's just good business. But it's more than that. Honesty breeds consistency and that's where real confidence, satisfaction, production and dedication is derived from those around us. How we are perceived often drives how we are treated by our co-workers and staffs. It's hard to follow someone who isn't truthful or who you don't believe in. Have you ever had a manager who liked to keep bad news from the customer? Or a co-worker who was less than honest with senior management? I have. It's hard to give these people respect and to follow their direction, because you know they are working more in a self-serving mode than one that is in line with the goals and mission of the organization and likely they are working in direct contrast to what is in your best interest. These individuals may obtain leadership positions, but sooner or later (hopefully sooner), they fall or misstep and no one wants to be on their side of the fence when that happens.


Be an attentive listener. Communicating isn't just you talking. It is also you listening. The best communicators, over time, are the truly good listeners. As we conduct our meetings and disseminate information to our staff and project team members and extended stakeholders, it is critical for us to be listening to the feedback we are getting during meetings or sessions. It's that critical step of listening that tells us whether or not we communicated effectively and if our audience “got it.” I recommend – highly recommend – following up all meetings with notes to attendees asking them to review, revise and return in order to ensure that everyone is still on the same page. But by listening well during meetings some miscommunications and misperceptions can be corrected even before the first person leaves the room or call.


Keep everyone informed. It isn't just about communication. It's about information distribution. It's about timely and efficiently led meetings. It's about regularly producing status reports that provide meaningful information, data and...well...status. The project manager or individual who makes sure that key stakeholders are up to date at all times can be assured that those individuals will be more ready, willing and able to help – productively and efficiently – when needed for information and decisions on a project or series of tasks.


Summary / call for input


The best of the best are able to get the most production and efficient work out of those around them. The best project managers are able to get the most out of their dedicated and skilled project team members. The best CEOs get the most out of their companies and employees and investors because of their dedication, hard work, vision and integrity. The best consultants get the most out of their clients and individuals they are working with because of their honesty, fair practices, and timely delivery. It's about doing what you say you're going to do, acting as others expect you to act, and ensuring that everyone is on the same page and working toward a common goal. These five key tips that I've alluded to in this article help you to get to that point, but I know there are more.


Think about ways you draw the most and best work out of your team and following? What characteristics shine through from the best leaders you've known throughout your career that seem to get the most out of those around them? What on this list do you agree with? What would you add to it?

I wish I could tell you that if you have a cybersecurity plan then you’re covered. But you are not. Why? Because the hackers and the blackhats and the pursuers on the Dark Net and the Dark Web are one or more steps ahead of all of us all the time. If they weren’t, then there would be no security breaches or identity thefts or deadly hacks.


With that said, here are three key reasons why your cybersecurity plan is outdated and needs to be revised….


If it wasn't created yesterday, then it's outdated. Everything can be hacked and the best blackhats are already two steps ahead of the best prevention plans anyone has. In reality, what we think is cybersecurity is really just reactive cyber defense against what happened to someone yesterday. We can anticipate what the next hack might be and build software and technology defenses against it, but that’s like trying to anticipate what might kill you tomorrow when in fact you could step in front of a bus accidentally and you probably didn’t plan for that one. You’ll never really be proactive, only reactive.


You need to hire a CSO or consultant and have them review and revise it. You planned security out with the personnel you had in charge at the time and that’s great, but hacker activity is increasing daily and targets are constantly changing. You likely need a Chief Security Officer (CSO) or at least a lead security director or analyst who will guide your organization down a finer tuned path to mitigation and avoidance of cyber criminal activity. Bottom line…you need to spend more time and get more technical expertise on board quickly to do any good in combating the potential for cybercrime affecting your organization…especially if you have sensitive data or are a larger organization with a potentially large database of customer information.


Look at your projects and clients from their side. You thought about security and cybercrime potential from your side and your potential liabilities. Now stop and look at it from your clients' side. What happens to them if some blackhat activity seriously breached their data or puts their multi-million-dollar project with you in jeopardy? What would be the reaction of your very important client base? What would be the sudden drop in revenue you might experience? What costs would they incur and what would your responsibility to them be? Think liability…


Summary / call for input


The bottom line is this…if you weren’t too worried about cybercrime affecting you and the need for cybersecurity in your organization before…well…things have changed. 2016 is going to be different than 2015. And not for the better…which is bad because cybercrime is only increasing in number of incidents and overall costs year over year. According to a CBS.com article accompanying information about their CSI Cyber show (which is one of my personal favorites):


“In 2014, 47% of American adults had their personal information stolen by hackers — primarily through data breaches at large companies. In 2013, 43% of companies had a data breach in which hackers got into their systems to steal information. Data breaches targeting consumer information are on the rise, increasing 62% from 2012 to 2013, with 594% more identities stolen. That added up to a staggering total of $18,000,000,000 in credit card fraud for the year.”


Those are harsh numbers…and they are only getting worse. The question is…what are you or your organization doing about it or what will you do with this info? Do you have a cybercrime or cybersecurity plan in place? Do you have a team and infrastructure? Is it part of your risk planning already or are you in a reactive planning mode only? Please share and discuss.

There is no question that project success is hard to achieve. More than 50% of all projects are usually considered failures by someone to some degree using some yardstick. Surveys generally put project failure rates between 46% and 57%. Not good... not encouraging. Enough to make a newbie or would-be project manager go run and hide under a rock, right?


There are usually three key ingredients to project success in most stakeholder's books: on time delivery, on budget delivery and project customer satisfaction. So what we are discussing here is a major factor in project success. From my experience most stakeholders find a 10% budget overrun generally acceptable. Plus, it's way more easy to correct a 10% overrun if you have to than it is a 50% budget overage The key is to always know where the project financials stand and you do that by reviewing, revising and re-forecasting weekly. Let's go through what I prescribe to as my own 5 key practices to creating and managing a workable project budget.


Reviewing the project pricing and initial high level project schedule. When creating the budget from the start of the project, you're going to want to start with whatever the sales person or account manager left off with. Because that is where the project price came from. Some time and thought and effort has gone into coming up with at least a high level list of requirements, schedule, resource plan, budget and price and it's going to be the project manager's best jumping off point. No reason to start over from scratch... that would only serve to frustrate a project customer who is anxious to get started.


Revising the schedule with real resources and understanding the resource effort load. You may not have a real or full team assigned yet, but you can go back and assess the draft info from sales and derive your resource plan for the project based on what they put together, any statement of work (SOW) you may have, assumptions that were documented, and the draft project schedule and high level tasks that were put together.


Converting the resource plan into project dollars. Next it's time to put those thoughts and draft numbers and historical numbers to use. For example, on a technical project, if you have a Functional Design Document (FDD) to put together and you know that usually takes 60 hours of a Business Analyst and 40 hours of a Technical Lead to put together and produce plus another 20 hours for team member peer review and 4 hours for customer discussion then you know also – in general – the roles and prices to plug into and you'll probably come up with a price of around $20,000+ at the going rates on projects for those positions. You'll probably have a fairly similar price in place for a Technical Design Document (TDD) that the dev resources will actually build a tech solution from. You continue doing that till you've built a fairly reasonable and complete resource plan and thus, have a fairly reasonable and complete starting project budget. What if it differs greatly from the price? You hope it doesn't but it might. You may have worked up to $1,130,000 worth of effort and the project that was sold was for a price of $750,000. Now you have a problem. Ideally, and in most situations on a tech project, the customer is giving an estimate and possibly a “not to exceed” price but sold as a time and materials project. That's best case, but still you have to explain now a potential 51% higher price (($1,130,000 - $750,000) / $750,000) to the project client and help them up off the floor.


Maintaining the budget and forecast on an ongoing basis. Next, the ever important process of maintaining, reviewing and revising the project budget forecast every week. You can put it together and leave it, but that is a definite recipe for disaster. Make connections in accounting, do whatever you do to have quick and easy access to weekly project charging and financial information and plug those into whatever tool you are using as your project financials and project resource forecasting worksheet. For me they are one in the same and my template is a self-built spreadsheet that I still use and have as a free download on my website... you are welcome to it.


Making sure your team is charging accurately to the project. First, let's go by the assumption that we are working in a matrix environment where project resources are requested and borrowed on a project by project basis and that these resources don't officially work for the project managers but rather for department managers (like application development managers for the technical development resources). Every resource wants to appear to be 100% - 120% productive for work and performance review purposes. Every department manager who manages these resources wants the same thing. What does that mean? That means that you – as the project manager – know that each resource is planning to put 40-50 hours on their timesheet each and every week. Those hours have to go somewhere.


We'd like to think that all resources revise their time sheets every day, but we know that isn't true of 98% of the working resource pool. I've never done that as a developer or project manager and I've only known maybe two people who completed their time sheets like that. No, most wait till the 11th hour – often the following Monday when accounting is screaming for last week's time sheets – to document their project charges. They know they worked 50 hours, but can only remember details of about 40 of those hours. Where do the 10 “grey” hours go? To your project if they think you're the project manager who might not notice. Don't let that be you.


How do you keep resources from charging those grey hours to your project? Make a budget review part of your weekly project team meeting so that your team understands how closely you are watching the budget and how important financial accuracy is to you and your project. Do that and I guarantee that your project will not be the project receiving the grey hours to get their time sheets to the 50 hours that they know they worked. It will help keep your project financials in a manageable status and keep the project budget from going way over budget and surprising you some "grey" Monday morning.


Summary / call for input


The budget is critical to successful management of the project. Let your tool or spreadsheet help you, let accounting help you, and let your team help you (make them help you!). your job is hard enough as it is and managing any project budget - no matter how big or small - can be extremely difficult.


Project managers out there - what are your experiences with this? What tricks - and steps - have you employed to make sure you are creating and managing a workable and accurate budget. I've always said a 10% budget overage is usually acceptable and definitely easier to correct than a 50% overage that is usually too difficult and too late to overcome. Stop the bleed before it happens! Tell us how you do that.

Still running waterfall projects or development initiatives and need the push to go agile? Contemplating agile but you need some easy to explain reasons to go to your senior management with in order to get them to say “yes” to the conversion? Don't mention completing projects on budget because the whole concept with even estimating development costs on an agile project is a tricky one – we will cover that in another discussion soon. Right now I want to help those project or dev leaders through the negotiation process of getting agile in your organization.


Try going to your leadership with these five reasons...


Small teams more efficient than large teams. Smaller and more efficient teams can help reduce costs. Believe me, I've managed development teams of more than 25 app developers in size on large government projects and there was nothing inexpensive nor efficient about it. And I was only managing one of three such teams on the project. Our vice president at the time said we couldn't lose money faster if he was driving down the street with a car full of cash and all the windows open. And he was right. But we wanted to win the project badly and we did so we were faced with a huge system conversion project and felt we had no choice. Hindsight may be 20-20.


Less re-work. Agile dev teams are usually smaller and run more efficiently because they are focused on a smaller set of requirements during each sprint and focused on rolling out a new functionality in a very short period of time. Not much can fall through the cracks that way. By focusing on a smaller set of requirements, there is less chance to screw up and, therefore, much less chance for costly re-work. Plus, anything that does get overlooked can just be included in the next new functional roll-out.


Perfection is not required to stay on track. As just mentioned, if something is overlooked, it isn't the end of the world. I ran a $1.2 million software implementation project for a large government entity while at a professional services organization. The dev manager overlooked something very critical which resulted in a large amount of rework which used up all of the budget when we were only 60% through the engagement. It ultimately resulted in the cancellation of the entire engagement. What a waste. This is an extreme example and agile would not have saved that project, but in the agile world, if something is omitted from a sprint, it can go in the next functional rollout. No high costs, no big rework.


Better customer engagement. Because things are happening rapidly, you will often find you have better customer engagement in the project activities. Review and rollout is happening in short bursts so your customer can ill-afford to disappear for days on end as they sometimes do on waterfall projects where their other day job gets in the way.


Progress is obvious very early. Customers like this one. During long waterfall projects some project clients get uneasy as they see budget being expended while planning is happening – long before the “real work” starts and very long before they see any tangible fruits from that effort. Not so with agile – they see progress and functionality early and often. As long as it's done right, agile can keep customer satisfaction very high.


Summary / call for input


There...you now have five decent arguments. The weight each of these will have in your organization will, of course, depend somewhat on the complexity of your projects, the customers you are involved with and the type organization and industry you are in. Good luck.

How about our readers – have you ever had to go to management to justify a change like this? What additional reasons would you give for wanting to change your organization into an agile one? We all know that going to management with good arguments will help you with your case so for those of you who feel strongly about agile vs. waterfall please share your thoughts. Thanks!