Susan Cain just wrote a piece in the NY Times talking about the destructive force of groupthink (article found here: http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-new-groupthink.html?pagewanted=all). This started me thinking how groupthink applies to project management and the synergy created or hampered within a project team.
After reading the article I am more convinced that as a project manager it is important to encourage and draw out people’s experience and opinions. It is imperative that project teams have a voice and strong leadership to maintain project goals while remaining open to the team voices. Otherwise, we have the inverse problem. Instead of shortsighted groupthink that has little innovation and a blind rudder. You get analysis paralysis where the goal is clear but the wheels just spin. Which is worse? Probably about the same…nothing gets done, or it does, but it is completely wrong and misses the mark. What do you think?
Ever Have One of Those Meetings?
I was in an important meeting and the project team pretty much knew that a certain person wasn’t carrying their weight. This person wasn’t a complete let down…but could do more. During the course of our project meeting an issue was raised as to why a task had not been completed. This person became defensive and started pointing fingers and making excuses. I lost it. A normally mild manner person, I let him have it. I gave him the what for and how come. However, I was out of line and spent hours in one on one meetings apologizing to this person and the rest of the team. There is a time to kick someone in the pants and a way to do it. My way that day was wrong. It costs our team more time in apologizing then this person not completing their task. The bottom line is we have to play the game with the team that we have. There isn’t always time to replace someone and many times there isn’t anyone else available…period. My advice…if you aren’t getting the job done, own it and move on. People respect that more than excuses. Secondly, be slow to speak or you may make a situation worse. I know, because I did
Negotiating and Managing Project Expectations
One of the many factors in project cost overruns is due to setting unreasonable expectations. Whether working as a consultant outside a company or as a project manager within a company, all too often we become “yes” men to secure a deal or please superiors. We may win in the short term by getting the job or by delaying management’s wrath by telling them what they want to hear, but, in the long run, both scenarios are losers. As a consultant you land the gig and wind up with bad word of mouth advertising as being late and over budget. As an internal project manager you develop a reputation of being unreliable and/or overly optimistic. Instead, be real and upfront about duration and costs of expected projects. Give pushback to help set reasonable expectations. Maybe someone else will promise the moon? You should challenge competitors’ unreasonable assertions. You may still wind up losing the deal, but in the long run you will maintain your reputation and eventually land more deals because of it. Short term pain for long term gain is tough in this economy. What is your word worth and where do you go to get your reputation back?
The Gantt Chart and Daily Project Coordination
All project managers have used or at least heard of a Gantt chart. The Gantt chart was created by Henry Gantt around 1910 and still widely used today. It was used in major projects like the Hoover Dam. Henry Gantt designed the Gantt chart to help manage project scheduling and work progress. If you read his book, Work, Wages, and Profits (1916), you will note that Gantt believed it was imperative to communicate daily schedules to key players and by not doing so rendered schedules useless. Gantt thought it was important to be a project coordinator, to coordinate activities, and reduce conflicts. I think this is an important and often overlooked part of being a project manager. We often look at the larger picture and fail to identify “Daily” influences that cause project slowdowns. We should have daily expectations and identify barriers to those expectations each and every day.
Reference:
Gantt, H. L. (1916). Work, wages, and profits. San Diego, California: University of California Libraries.
Small Bites
I like keeping project tasks really, really short. A week-long task is sometimes too long, but obviously satisfying when finished. I also like keeping product releases very short. A release might have only a few of these short tasks. That ensures that the product is always within a few days of release. Project scheduling is simpler when tasks are short.
Let’s do a meeting!
Does your company do too few meetings? Yeah, you heard me right… too few.
If you’re like most corporate employees, you’ll answer, “Definitely not!”
Most of the scenes in the Dilbert comic are in meeting rooms. That should tell you what Scott Adams thinks of them. Meetings are the first signs of death in a once vibrant company. But beware; lack of meetings may spell the same results.
Meetings done right should get your blood pumping for action. You should go away wanting to try something new, or hoping for change, or at least inspired to follow. Make that the aim of your next meeting!
Timesheets are boring
Why get passionate about a boring timesheet tool? They are little more than cells and dropdown choices that collect your time and expenses. An endless bucket. Pointless. Employees reluctantly fill in those monotonous little cells every Friday afternoon or Monday morning for the week prior. Time tracking is a chore with little value.
Okay, that’s one perspective…
But have you ever viewed them as an investment? Like pouring value into your organization that you can mine later? Consider that for a moment.
What if you could magically predict how long your next project would take? Or cost? What if you could walk into the next meeting with hard evidence that your company talents are unfocused and distracted? That you are fighting too on many fronts? And in too many battles without clear endpoints? Wouldn’t that be worth documenting your time for.
That’s what time tracking gives you, among other things. Still see it as a boring chore?
Do you like Project Robots?
You just buried your mom and returned from the funeral. You’re a Project Manager on a high profile project for one of the largest tech companies in the world. It has only been one day since the funeral and you are still raw with emotion. Now imagine that you get an email informing you that you are not getting a break from the loss of your mom, but in fact, your workload has been increased. How about a spouse fighting cancer? Need a little time? No! Instead, how about an increased workload? Sound crazy? Well, imagine no more…these are true stories. This brings me to an important point.
In talking with a friend of mine with 26+ years of project management experience about Agile vs. Waterfall methods, he said, “You can have all the methods and processes you want but it all comes down to personal relationships and human intervention”. This gentleman was responsible for one of the largest SAP installations in US history. I was taken aback by the simple answer when he stated another simple cliché, “Take care of your team and your team will take care of you”, which means that they will take care of the project.
The examples given in the beginning of this blog are not meant to say that we shouldn’t be tough or suck it up. However, besides being in my opinion morally wrong, it is flat bad for business. Is the man whom just buried his wife still ready to climb that mountain for the team? Or, is he waiting for the first chance to jump ship?
All too often we pay lip service to our employees, “Let me know if you need any more resources”, while completely ignoring the realities of life.
I guess the bottom line is we can keep on pushing the machine, but what happens when the machine navigator gets ran over? Does the machine keep going and if so, who is driving…a robot?
Make sure when you ask someone if they need help that you don’t ignore the reality that is staring you right in the face — unless you like robots.
Time estimates are tricky
If you are an inexperienced project manager, engineer, or designer, consider tripling your initial time estimates for projects. That’s not a slam. It’s just that new managers don’t take a lot of minutia into consideration when developing project time estimates. Experienced people have been through a lot of project cycles. They have seen a lot, and the know the hundreds of little things that can bog a project down or extend it long beyond all normal estimates. So if you’re new, triple the schedule until you know the details.
7 Things You Need to Know About Development Project Estimations
Whether you are a project manager planning for a smooth implementation of a plan or a project sponsor on whose decisions a project depends, you cannot escape from the fact that project estimation is essential to its success. In the first place, there are three basic requirements that a project must satisfy: schedule, budget, and quality. The need to work within these essential project boundaries poses a huge challenge to everyone in the central management team.
There are various aspects that affect project estimates, such as team skills and experience levels, available technology, use of full-time or part-time resources, project quality management, risks, iteration, development environment, requirements, and most of all, the level of commitment of all project members.
Moreover, project estimations do not need to be too complicated. There are tools, methodologies, and best practices that can help project management teams, from sponsors to project managers, agree on estimates and push development efforts forward. Some of these include the following:
- Project estimates must be based on the application’s architecture. Making estimates based on an application’s architecture should give you a clear idea of the length of the entire development project phase. Moreover, an architecture-based estimation provides you a macro-level view of the resources needed to complete the project.
- Project estimations should also come from the ground up. All estimates must add up, and estimating the collective efforts of the production teams that work on the application’s modules helps identify the number of in-house and outsourced consultants that you need to hire for the entire project, as well as have a clear idea of the collective man-hours required to code modules or finish all features of the application. Ground-up estimates are provided by project team members and do not necessarily match top-level estimates exactly. In this case, it is best to add a percentage of architecture-based estimates to give room to possible reworks, risks, and other events that may or may not be within the control of the project staff.
- Do not forget modular estimates. Once you have a clear idea of the architecture, it becomes easier to identify the modules that make up the entirety of the application. Knowing the nature of these modules should help you identify which can be done in-house or onshore, or by an offshore development team. Moreover, given the location and team composition of each development team that works on a module, it becomes easier to identify the technical and financial resources needed to work on the codes.
- Development language matters. Whether the development language is Java, .Net, C++ or any other popular language used by software engineers, team that will be hired for the project must be knowledgeable in it. Some development efforts require higher skills in these languages, while some only need basic functional knowledge, and the levels of specialization in any of these languages have corresponding rates. Most of the time, the chosen development language depends on the chosen platform, and certain platforms run on specialized hardware.
- You cannot promise upper management dramatic costs from offshoring. While there are greater savings from having development work done by offshore teams composed of workers whose rates are significantly lower from onshore staff, you must consider communication, knowledge transfer, technical set-up, and software installation costs in your financial estimates. Estimating costs is often more about managing expectations, but as the project matures, it should be clearer whether the money spent on it was money that was spent well.
- Project estimation software and tools help identify “what-if” scenarios. Over the years, project managers have devised ways to automate project schedule, framework, cost, and staffing estimates. Some estimation applications also have sample historical data or models based on real-world examples. If your business has a lot in common with the samples in the estimation tool, it can help you identify what-if scenarios and in turn include risks, buffers, and iteration estimates.
- Price break-down helps in prioritization. Breaking down the total cost of the project helps management decide which parts of a system should be prioritized, delayed, or even cancel. Estimating costs for a new project may not be easy, but project sponsors and managers must be able to know and agree on the breakdown of costs of development, technical requirements, and overhead.
By ExecutiveBrief -online resource on process management, project management, and process improvement.