Can Agile Work in a Consulting Structure?
| I recently attended my first PMI global congress and was struck by how many of the ideas presented confirmed my current thinking. I also learned new techniques and angles to consider for the issues I face daily in a non-traditional project management environment. In John Stenbeck's session, "Agile PM Mastery in 60 Minutes, Guaranteed!" he had a fantastic way of boiling down the essentials and explaining them in a way that traditionally trained project managers easily understand. Many agile proponents will tell you that the methodology will work within almost any environment that traditional waterfall methodologies will fit. In fact, there's one comment on my previous post suggesting that the issues that I've described -- like needing faster time to market and the ability to address fluid requirement -- would be addressed by implementing agile. I see a big gap, though: staffing. Agile works best when you have a dedicated team for the life of the project -- or at least the sprint. But many "consulting-structured" organizations rely on their ability to maximize cost benefits by pooling resources. This means assigning one person to two or more projects at a time. That strikes me as a big issue for an agile team structure. So, in a non-traditional environment with team members who aren't always dedicated to one project, what are your options in terms of attempting to implement agile? I look forward to hearing your thoughts. |
Resource Movement and Management
Categories:
Teams
Categories: Teams
| The IT industry is growing—and that means more work for project managers. This is good news, but it also means teams need more people to complete the work. While recruiting for new talent, project managers have to optimize existing team members as best they can. Some times people may be moved from one project to another, but such changes can make it hard to control the triple constraint of cost, quality and schedule. Here are my observations on how so many moving parts can impact project delivery: 1. Long-running projects require more time for people to adjust. New team members need about six to eight months to understand the project and its processes. 2. Learning curves vary. An experienced newcomer can still take awhile to become 100 percent productive. Someone just starting out may take more than a year. 3. Getting the highest-quality team members may not be feasible because of the urgency, availability and cost involved. Leverage the strong resources you have. 4. Team leaders may have less time to devote to the project. Taking on new project members could force the team leader to focus on daily tracking, resolving team issues and client communication, and less time to work on the project. 5. Implement an induction plan. It can take three to four weeks to get a replacement for a team member who resigns or leaves the team. Teams can most effectively deploy new additions by following a regular induction plan to get them up to speed on the project and culture. 6. Be flexible. Some people may perform poorly because of the project's complexity, domain, technical knowledge or their interest level. However, that same team member might do well in a different project. 7. The estimate for completing a task always differs from the actual effort. This is more severe in long-running projects. The client expects us to have complete knowledge of the system, which is not always true because of internal movement among team members. 8. Teams can work smarter on projects on a fixed bid and when work approval comes in small modules. You can have multiple modules running parallel in different phases, but there will always be some idle time in between. What do you say? |
Does Work-Life Balance Really Exist?
Categories:
Career Development
Categories: Career Development
| I spent a good part of a recent weekend doing a final edit of an upcoming project management book. Ironically, one chapter referenced a 2004 Fast Company article called "Balance is Bunk!" ('Bunk' being a slang term that basically means 'absurd.') There I was, giving up my well-earned leisure time on a beautiful fall day, but wanting and needing to get the job done. So I went to the article, which states: "The truth is, balance is bunk. ... The quest for balance between work and life, as we've come to think of it, isn't just a losing proposition; it's a hurtful, destructive one." Now we're really getting to the core of the dilemma, I thought to myself. The author then quotes John Wood, who at the time the article was written, had been working seven days a week, 365 days a year. In regard to the elusive, so-called state of "balance," Mr. Wood said: "I don't look at balance as an ideal. What I look at is, Am I happy? If the answer is yes, then everything else is inconsequential." That made a lot of sense, I thought. I love and am passionate about what I do. I want to get this book published and out the door -- but what's on the other side of this supposedly unachievable quest for balance? Rodney Turner, PhD, recently made a presentation entitled "Work-Life Balance in Project-Oriented Organizations." A preview states: "Companies should treat their employees with respect and allow them to have a work-life balance. It is good for their physical and psychological health and therefore good for social sustainability. ... The need for profit and responding to client demands often takes precedence over employee wellbeing." Hmmm. So is work-life balance bunk? I think the answer is both yes and no. Sometimes when a project grabs us or is imposed on us, we have to say, "I surrender" -- either out of passion, guilt or intense pressure. I chose to give the book I was editing my all -- even when a "balanced" work-life scenario would have had me walking in the woods on that beautiful day. But I know it was worth it, and I know other beautiful days will come. I need to make sure I take advantage of them -- at least once in a while. What do you think about the work-life balance challenge? |
Deliverables Are Only the Beginning
Categories:
Teams
Categories: Teams
| Simply supplying a project's deliverables is not enough. Project managers must understand the goal of the project, the objectives to support that goal and the deliverables needed to fulfil those objectives. Goals describe a project's overarching purpose. They tend to be wide-reaching and related to senior management and client expectations. A project's success depends on achieving its goals. Objectives fall into two broad categories: • Objectives achieved by undertaking the project work in an appropriate way, such as addressing safety, sustainability, work force development and stakeholder management. • Objectives achieved as a consequence of completing the work of the project -- successfully creating the deliverables transferred to the customer to meet the requirements defined in the project's scope statement, for example. Objectives are the direct responsibility of the project manager, and he or she should be assigned the authority, responsibility and resources to achieve them. Deliverables are the final product from either the project management processes or the performing organization. A successful delivery hinges on achieving the specified requirements of time, cost and scope while satisfying the key stakeholder's requirements. There's more to project management than just deliverables. Focusing on them exclusively to the detriment of the project's objectives and the organization's goals is counterproductive. Project managers must understand how their deliverables will contribute to overall goals of the organization. |
If You Can't Keep Your Word, Honor It
| We often talk about keeping our word -- making a commitment and sticking to it, no matter what. But we don't often talk about honoring our word -- acknowledging when we can't meet a commitment. There will inevitably be times when we can't keep our word as circumstances change for one reason or another. Say you've committed to meeting a milestone on a specific date, for example. To keep your word, you have to do whatever it takes to make that date. But to honor your word, you only need to follow up with the person you made the commitment to and clarify why you can't meet the deadline. I'd also recommend recommitting to a different date, time or scope. This way, you're not simply hiding and hoping that things will work out, or that you won't be asked about a deliverable. Be confident enough to raise the issue directly, knowing that it will maintain a workable relationship. Even if you're unable to deliver as promised, you can at least be relied upon to raise red flags early enough, without downplaying the severity, to allow the client or team time to align their activities accordingly. And that saves time and money. To maintain a healthy relationship on your team, you must honor your word. It impacts the results of your work, your reputation, and your ability to earn a renewed trust from your clients and project team members. Honoring your word restores your integrity and creates workability. But the better you assess estimated target dates for the project tasks and milestones and your ability to manage your day-to-day activities per your own commitments to others, the easier it will to keep your word and "do it right the first time." |
