​The customer’s perspective


You know the story – a customer comes to you with a project and they have it all mapped out. They know what they want. They know how they want it. They know the technology they want to utilize for the solution. They may even know how much it’s going to cost and how long it’s going to take.


The project manager’s perspective


Now let’s look at your situation. You’re a busy project manager and your plate is full. You’re juggling six projects already with six different project teams and six different customers. That means you’re already babysitting a lot of people and making a lot of things happen. This new project comes to you with everything planned out in advance by the customer. Talk about easy street. And after all, it is the customer’s money that’s being spent so they must know what they want. Who are you to tell them what they should be spending their money on? And if it all goes up in flames, it’s their fault anyway because this is what they asked for.


STOP! It’s sounds wonderful, but do not go down that road. It’s incredibly tempting to take the easy road and just do what the customer wants. At the end of the day, it’s their request you’re implementing so if things go south, you can blame it all on them. WRONG! When the dust clears at the end of the project and your customer is left with a bunch of frustrated end users because you rolled out a solution that they asked for, but not one they needed, then it will be your head on the chopping block. Remember, it’s always the project manager who has the target on their head. Don’t kid yourself that an unhappy customer will accept the blame. No, it’s your job to look at their issues and ask the right questions to find out what they really need. It’s not your job to just placate the customer.


Here are four steps that the project manager can go through to basically morph the project from the customer’s wish list into a real solution. There are variations to this and what works best may depend on the customer and what your organization’s processes mandate, but to some extent this is basically what needs to happen. It may be easy, but sometimes it isn’t because the customer may have to hear some tough news – like their ‘real’ solution is going to cost five times what they were originally expecting.


Hear the customer out


Obviously, the first thing your project team must do is ride it out with the customer. Sit down and go through the package you’ve been given. Accept their requirements, their wide-eyed ideas of how things are and how things should be, and generally be all ears. Ask questions, but don’t be combative. Don’t deflate the customer’s enthusiasm at this point because they may really know what they need. At this point it’s your job to review the requirements they’ve documented for you and try to get some more detail attached to them. You really don’t know their business yet.


Interview the real users


As the project manager, it’s critical that you’ve built the proper amount of planning time into the schedule. Even if it seems like it’s all planned out and the customer has everything under control, you have to assume that’s not the case. So, now it’s on to the next phase of the planning process. Ask you customer to gather subject matter experts (SMEs) and end users (they may be one in the same) so that you can interview them. After all, you need all sides of the story, right?


Before you show these individuals what you and your customer have compiled so far, find out where things stand from their perspective. Discuss the goals of the project and see if they line up with what they need to really do their job well. Once you’ve done that, then you can bring out what you’ve documented so far. Show them the requirements, the potential solution, and get an understanding of the ‘gaps’ that still remain between what the customer thinks they need and what their end users really need.


Revamp the quote


Assuming you found more than just a little ‘gap’, you must now go back and rework the project schedule, the estimate, the timeframe, the resource plan …. basically everything. Make it as strong a case as possible because if you’ve found a significant gap, it’s going to take solid numbers and documentation to back it up if you’re going to convince the customer that they were way off in their original perception of the problem and the solution.


Break the news


Now it’s time to regroup with your project sponsor or customer project team. It’s time to present your latest findings to them and go through what you believe to be the ‘real world’ vision of the project schedule and cost. Remember, you can’t toss everything out from your original work. There’s that outside possibility that the customer won’t signoff on your version of the ‘real’ task at hand and will instead require you to move forward with their plans.


If that is the case, then you have a tough decision to make … or your company leadership has a tough decision to make. Do you go down the customer’s path with them knowing you may be delivering the wrong solution and laugh all the way to the bank? Or do you end the project right there knowing you’ll never make them happy? My preference is somewhere in between because I believe that in most cases, with the proper presentation you can sway the customer over to the right solution. But this is not always going to be the case and there are times when you have to cut your loses and say goodbye. Ending the relationship at that impasse rather than risking permanent damage to your reputation is usually the best path to take.


Summary


It’s not always easy to take the steps necessary for the PM and team to get from the initial project request, through to the real problem, define the requirements and provide a satisfying solution to the customer.  You want to trust that the customer understands the issues and can figure out what is best for them, but that is not necessarily the case – that’s why they brought in the experts in the first place. You just have to make them realize that sometimes. Just remember that there's almost always more to the underlying issue that necessitated the project than what originally meets the eye. And if all you do is provide a solution to what they originally request without going deeper, you can easily end up with a dissatisfied customer and frustrated end users at the end of the project.


Never forget that when the project gets to the 11th hour and the SMEs or end users are testing it out and are telling their superiors that this solution doesn't do the trick, the customer will come back to the PM looking for blood.  It doesn't matter how much they said they knew what they wanted ... the bottom line is the PM didn't deliver and that is what the customer will take away with them.

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


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


Hooking up with the client


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


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


You’ve made the wrong choice


There will be times when you determine that you’ve made the wrong choice. You’ve decided to move forward with a client who is or is going to cause you lots of headaches. They may be unethical. They may refuse to pay for services rendered even though you’ve delivered good work. They may continually try to push scope but balk at paying more. They may call you at all hours of the day and night. Whatever the problem or frustration, you’ve realized you made a poor decision to work with them.


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


The exit strategy


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


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

Most tech books are what they are: a boring logical take on a topic we've all covered a few times already. Disappointment at the hours you can't get back for the time you just spent reading a book that didn't really offer you anything new.


And then there are others that cover a timely topic and manage to both keep it cutting edge and interesting. My latest find falls into that category, thankfully. The title is “Digital Project Practice - Managing Innovation and Change" and it is a collaboration of work from 13 top authors and experts in related fields...

• Aditya Chandak - Group Product Manager at Walmart eCommerce
• Dr. Majid Dadgar - Assistant Professor of Business Analytics & Information Systems at University of San Francisco
• Ralf Dick - Freelance Agile Consultant
• Elena Dinman - CEO / Founder at Myfreedom IT School
• Dr. Tobias Endress - Freelance Business Consultant
• Günter Jeschke - Consultant at 1st solution consulting
• Dr. Stephan Meyer - Consultant Digital Transformation at www.denkstelle.com
• Dr. Marc Nathmann - Legal Counsel and Attorney at Law, ING Germany
• Dr. Anton Pussep - Project Leader IT at VNR Press
• Girish Ramachandra - Senior Manager at Wipfli LLP
• Beatriz Alzate Richter - Senior Product Owner at Yara Digital Lab
• Dr. Bernd Thommes - Managing Partner at Antal Germany
• Patric Zeier - Consultant, Mediator, Coach, Senior Project Manager

What is actually meant by Digital Project Practice?


What does Digital Project Practice mean? You could define it like this: Digital Project Practice is the (applied) art and science of managing technology related projects from concept to completion, within budget and using a certain amount of resources. It involves planning, delegating, tracking, reviewing, and measuring results — often done using project management software. The goal of every project is different, but the overarching objective is to grow business and see valuable ROI from the project. Types of projects can range from online projects to streamlining complex enterprise processes.


This book dedicates a good 25+ pages right out of the gate on a pet peeve of mine on the topic of failed projects, what the perceptions are of project success and failure and is it really failure. I won't give any of it away, but it is great material and great thoughts on the subject. If you're a seasoned PM professional you'll know the frustration surrounding the notion of project failures and successes...


If there’s one thing I’ve learned through the popularity of some of my own articles is this – focusing on PM problems and challenges and trying to address how we meet those problems and challenges is something that really resonates with the readers. This book definitely does a great job of presenting this type of material surrounding digital projects and you'll be left in a better position to deal with challenges of project change. I’m not saying that misery loves company – but I am saying that we all face these challenges as project managers just about every single day and any material like this is something an experienced PM looking to manage their next project better can devour and use to extract good, practical and helpful strategic info. You’ll enjoy these pages… trust me.


Great quote from later in the book when discussing some essential reading on managing diverse teams. “Project management is not a profession but an essential skill in achieving career success.” Nailed it – perfectly sums up how PM is really much more than a profession – it's more like a way of life and a way to manage your career over the long term. Great read.


Pros


The pros for me in this book are personal and professional preferences. It does a nice job out of the gate coming from a personal perspective from each author using experiences they've had along the way. That allows you to immediately connect with the authors and that's how I've always liked to connect with my readers over the years.


Also, all concepts about Digital Project Practice are discussed mostly in a team concept which I find to be a necessary project management view. Project Managers are essential - in my opinion - but the success, failure, communication and progress is a team function... not an individual. Good job.


The pros list could be much longer – and it is – but this review isn't meant to be the size of a book itself, so I will stick to three. You'll leave with a good understanding of how Digital Project Practice fits into to today's PM world and where it's going tomorrow. I consider that essential to really being useful as we are growing and learning and working to be more successful project managers.


Cons


There really aren't any in this book. The only one possibly being that it is a more technical rather than casual read for the average reader of this type of material. Don't get me wrong it is still a personal and experience-based presentation from each other. But that's likely just me as I've been writing more casual and from the hip type articles and ebooks for a dozen years – rarely more third person type content other than a few white papers here and there. It's more my style and that's just me. What it lacks in casual reading it makes up for in content, detail and useful insight.


Key Takeaways


This book is applicable to any level of experience for the project manager. New, very experienced, interested in PM – all levels will enjoy it and find their own information to take forward and use today and beyond... and keep referring back to this work for helpful information and insight for future successes. It's an excellent and relevant collection of thoughts from several experts in the field all in one place. Win. I highly recommend this book and you'll find yourself going back to it often.

There are probably a million possibilities for subtitles for this article. “If so, where can I stuff the body?” comes to mind. So does, “Surely there’s a mental institution somewhere that’s missing a patient.” But seriously, have you ever been in a situation where you were reporting to a PMO director and you wonder what value this person brings to the table? You romanticize about how much more productive you would be if you didn’t have to jump through his hoops. Better yet, you consider how much better off you – and all the other PMs - would be if you were running the show. Or at least if you got to handpick his successor. Am I striking a chord here? Of course I am.


I’m going to state what I think a good PMO director needs to bring to the dance. I’m hoping on the couple of occasions so far where I’ve run the show that I did bring these things to the dance. At least I know I tried. And I will say that sometimes the organizational chemistry and process flow doesn’t always allow for the utopia that I’m going to describe. But getting somewhere close would be nice.


#1 – Manage the PMO, not a bunch of projects


The PMO director really needs to be a leader of people, not projects. I’m so tired of seeing PM’s who are spending most of their time leading the big projects also acting in the role of PMO director. It’s just not right. The PMO director needs to establish processes, identify training needs, knock down barriers, make connections, and fight for the PMO’s presence in the organization. It’s how the viability of the PM processes is maintained. You can’t rely on the CEO to suddenly think what you’re doing matters. Not when so many projects fail or have major issues. No, someone must be championing the organization. That’s the director. If he’s leading five projects of his own, he can’t do that. No one can.


#2 – Know your organization


The PMO director must know the organization. He must know how get information, favors, resources, and support. Unless it’s a startup situation, it’s very difficult to bring in an outsider as the director and have them be immediately useful. It’s better to bring outsiders in as PMs and promote a good leader to this role.


#3 – Care about the PM’s, not the politics


The PMO director must be ready to fight for the project managers in the PMO like the PMs fight for their customers. I’m sorry, but if I’m being pulled two ways – one way by senior management and one way by the customer – it’s usually going to be the customer’s concerns that I react to first. Likewise, the PMO director should be more concerned about his organization and fighting for it rather than playing a lot of politically games for senior management – unless that is in the best interests of the PMO itself. So many PMOs fail, they need a strong leader fighting to keep it viable.


#4 – Communicate well


Above all else – just like with any project manager – the PMO director must be a great communicator. Company policies, processes, planning, etc. must all come from this individual. And he must be a good listener because there are lots of project issues that arise that PMs need help with. Their success must be his utmost concern.


Conclusion


So, can I fire my PMO director? Well, sort of. If the needs of the project managers are not being met and if the PMO is faltering because of a lack of organized, efficient, and effective leadership, then waiting will only mean projects will fail. Customers will be lost. The company bottom line will take a huge hit. And so will careers. Staying quiet is not in anyone’s best interest. If it’s a common feeling (and not just your own grudge) that the PMO leadership is ineffective, it must be taken up the chain of command. And yes, then you can fire your PMO director. It would be your duty to do so.

Remember the old MacGyver series? Angus MacGyver, played by Richard Dean Anderson, could get himself out of just about any jam using anything from silly putty to paper clips to a piece of string. He could even make a gun out of a pen. Yes, those things are a bit beyond the normal project manager, but we all have our fallbacks – the things we rely on to get us out of some of the jams we get ourselves into – or our teams or customers get us into.


But is that the right way? Do we want to use whatever happens to be convenient at the moment to help us around an issue? MacGyver had to because he was almost always dealing with situation of clear and present danger that had to be resolved at that moment. He didn’t have the opportunity for advanced planning or risk management to get him through the messes he faced. As project managers who should be utilizing best practices, we do – or at least we should.


If we get in the habit of looking for the quick fix to our project management problems, then we’re never going to learn how to avoid them in the future. We’ll never learn from our mistakes and we’ll find ourselves always relying on luck to get out us out of messy project situation. Eventually our luck will run out and we’ll be exposed for who we really are….a talentless project manager who has skated by on the ability to avoid project catastrophes that should not have been potential catastrophes in the first place.


If we find we’re stuck in one of those ruts…too busy to focus on the right way to do things and just winging it till fires show up that need to be fought, what do we do? How do we un-stick ourselves, especially when we’re fighting fires on three, four or even five projects at the same time? When I find myself in this type of situation, I follow these two actions to help get myself and my projects back to where they should be….


Go back to the basics


If you’re floundering, then there’s no better time to regroup and get back to the basics. When I’m overwhelmed on multiple projects I like to step back and take stock on where things stand and how I’m running each project. I usually come to the realization that I’m shooting from the hip on one or more of the projects, falling into bad practices because I’m so busy and I’ve let the daily demands of the project management activities lead me into bad habits. At this point I stop, regroup with my team on each project – sort of a mid-project restart or refresh – and I revisit the plans from the kickoff phase of the project. Am I following the communication plan, are we holding regular status meetings and producing status reports according to the original schedule? Are we reviewing issues regularly? All the slow and steady stuff that keeps projects on track – am I doing all those things? I usually find that several pieces of the puzzle are missing and once I get back to the basics and on track to doing what I originally planned to do and managing each project how I promised to manage them, things tend to get back to normal.


Offload a project


No project manager ever likes to say they’re overloaded. Actually, no professional with a good-sized ego ever likes to admit this. It’s the guy equivalent to asking for directions. But sometimes – in order to be successful overall – it must be done. If you’re so swamped that you’re sinking on all projects, then meet with senior management and ask to offload one or more projects. Ideally, if you’re running multiples projects, they’re in different phases and not all hitting stride at the same time. On the rare occasion that they are, it’s ok to ask for someone to take over a project from you. You’re management wants you to succeed, too, and they’ll likely admire you more for recognizing the problem early on rather than after you’re already drowning and the project is already failing.


Summary


Angus MacGyver had something the average project manager doesn’t have - a nice group of writers and an avid fan base wanting him to survive to see another adventure next week. His success was guaranteed. We don’t have that luxury. We must rely on PM skills and best practices and we must rely on our teams and organization to help us meet those project challenges head-on. We need to be prepared for the problems we might encounter – meaning we must act proactively rather than reactively to issues on the project. Preparedness through planning, risk management, and PM best practices will find us experiencing more project management successes than failures in the long run. But don’t forget to assess how you’re managing things right now and adjust your practices back to where they should be. And ask for help if you need to – you’ll be more successful on your remaining projects because of that call for help.

No one seeks out to be part of a failing project. No project manager in their right mind says, “I hope this project tanks.” It’s just not part of our human nature. That said there are just times when a project is beyond saving or two sides simply aren’t going to get to a point of mutual agreement on the outstanding issues. It may become clear at that point that moving forward is in no one’s best interest. How we close down such a project is probably something to be discussed in another article. I will make not of that and address that soon. But right now I’d like to look at some of the signs that can be indicators that the project may need to be laid to rest. Or at least halted until more information is available, better requirements are defined, a business structure has changed making the project goals clearer, or personnel who are getting in the way of progress are turned over.


I’m interested in hearing from our readers on reasons that projects may need to be shelved. For me, I’ve identified what I feel are the four main reasons I’ve witnessed either in my projects or in my colleagues projects. These four are:


Scope creep is continuous


I’m not talking here about small disagreements in where the line in the sand needs to be drawn in terms of project scope. There are rare cases where the kickoff meeting happens and you move into planning with the customer and what you thought was a ‘defined’ project has turned into a mess. The customer expected ‘x’ and you planned to deliver ‘y.’ Sometimes it’s an issue that started during the sales process and wasn’t glaringly obvious until the skilled resources who truly understand the solution are sitting down with the customer and planning out the implementation. This is where the tire meets the road – often really for the first time – and the customer says, “wait, that’s not what I was told by Sales.” Or, “I was told I could have this for free and now you’re telling me that’s an 200 hour effort?” Sometimes these situations can be handled through negotiation and sometimes they can’t. When they can’t and it’s become obvious that you’re at a stalemate, it’s likely time to call the project off or place it on hold until clear and decisive plans can be made.


The project funding runs dry


When funding runs dry, the project manager has a serious problem. And without any documentation to support otherwise, the blame is usually going to fall to him. What can cause this situation? Well, if it’s just simply oversight or laziness on the side of the project manager, then that’s not grounds to cancel or shelve the project – but it certainly is grounds to remove the project manager for lack of performance. What I’m really referring to for the purpose of this article is more than just lack of budget oversight. My reference here is to situations where increasing demands are placed on individual project team members to perform outside of the planned tasks for the project. Perhaps it’s customer demands, perhaps it’s a need for many project personnel to go onsite for an extended period of time to work out project details, or perhaps it’s a customer’s wish to have one resource 100% dedicated to the project when that was not originally in the plan to do so. If change orders can be put in place – and if the customer has the money to move forward with them – then everything is fine. But if the customer refuses the change orders, thus refusing to pay more for the personnel demands, then you have an issue. Likewise, if the customer’s funding has run dry and the project is nowhere near complete, you also have an issue. Unless your organization is ready to go ‘pro-bono’ the rest of the way on the project, you may have no choice but to end or halt the project until more funding is available on the customer side.


Future project phases are being questioned


This one may not be cause to actually cancel the remainder of the project, but it is likely time to implement what you have, assuming you’ve got a workable solution through the phases already rolled out, and leave the rest of the project until the work is better defined. Customer priorities and infrastructure changes can cause future phases of a project to come into question. Are they still needed? Should the order of the phases be changed? It’s nearly impossible to keep your expensive project resources intact while the customer takes two months to decide so it’s usually a good stopping point to give the customer a chance to regroup and figure out how they want to spend the rest of their project dollars – and if they even want and need to.


Customer project personnel are constantly turning over


Have you ever had one of those projects where the customer team seems to be moving through a revolving door? Customer team members come and go, even the project lead on the customer side seems to change regularly. Team members often aren’t as critical as the actual project sponsor or leader – at least not for major decision-making. But if this turnover in customer personnel is causing schedule slippages, missed tasks, and budget overruns as your team scrambles with conflicting direction from the customer, then you have a major issue on your hands. Before the blame falls to the delivery project team and to you as the project manager, be sure to document the customer team changes well. Following that, if the situation is not improving and productivity has come to a standstill or major decisions are not being made, then it may be time to stop work on the project and force the customer to make some key ‘go’, ‘no-go’ decisions on the remaining work on the project.


Summary


The key here is knowing when to suggest to the client that it's not in the best interest of either party to move forward with the consulting engagement.
This discussion assumes one very big item that simply can’t be overlooked. That is that you can contractually cancel this project and that you would be in agreement with the client to do so. Be careful to not pull the plug on a project that would end up costing you millions in litigation if you cancel it. I would never suggest that – obviously. I’m simply looking at situations that arise that make it obvious – to at least one party if not both – that the project really needs to be put out of it’s misery.

One of the most difficult parts of the consulting engagement – for me anyway – is bidding the job. Not that it’s really that hard. If you’re busy and can take it or leave it with this potential new client’s business, then you listen to them, shoot them a fair estimate – but making it worthwhile and very profitable for you – and see if they want to move forward. And if they don’t, that’s ok because you have lots of work going on.


But if your business is a little slow at the moment or for some reason you really want this engagement maybe because it takes you into new territory or technology that you wanted some exposure to (but not at any cost, of course), then there can be several ingredients that go into your bid and it sometimes involves listening for cues from your potential client before you start preparing the bid in the first place.


I’m not implying that you cheapen your consulting practice or your expertise by slashing your rate. Never. I’d be more inclined to give away some free work before slashing my rate.  What I am saying though, is that you may need to look for tips from your potential client to know how to bid and what their concerns might be with your proposal before you even put it together.


Here are the three main issues that usually arise for consultants facing new clients:


Concern over your availability


The potential client has seen your website and client list and they’ve probably looked over your resume. They assume you have a pretty full plate and they may be right. They are concerned that they won’t be able to get you when they might need you the most. For me, I usually work around that concern by guaranteeing them that they will have ‘x’ number of hours access to me at a minimum every week. If possible – and I’ll get to this again down in point number three below – I try to go with an assumed number of hours – or range of hours – that they will get every week for a fixed retainer amount. That way they feel like they are entitled to that much access for certain and they then feel more comfortable that they’ll have you when they need you.


Concern over your expertise


The potential client may have concern over your expertise. Especially if the proposed engagement covers technology or process that you have similar experience with – but not specific experience with. Ease their mind by gathering as much info about their need as you possibly can, ask for any supporting documents so you can review them aside from a face to face meeting, and ask good, driving questions to let them know you understand the process and their need. Give them a little extra time – unbilled time – up front in the ‘discovery’ phase to get as much information as possible about the need and use that to plan out a good proposal that details your understanding and puts any expertise concerns they might have to rest. Most consulting expertise translates well across various engagements – the processes are similar even if the technology changes. A thorough and detailed proposal from you will convince them of that.


Anxiety over cost containment


This is a huge one – especially in this down economy. The minute you walk through their door to discuss a potential engagement, they’re already thinking about how to keep your expenses from going out of control because they know they need you but they don’t have an endless budget. If it’s obvious that cost containment is going to be a concern, then I try to give them a fixed weekly or bi-weekly rate based on an assumed number of hours. Of course, if the hours start to get out of hand, then the agreement calls for additional billing to cover your extra work. However, what I usually find is they are happy to pay the fixed amount and usually end up utilizing less of your time than was originally planned. Win – win.