Viewing Posts by Geoff Mattie
Can Agile Conquer the Physics of the Triple Constraint?
| I recently saw a presentation from an advertising agency that claimed it would be able to do what no other company had: It had figured out how to deliver complex projects (in comparison to other digital advertising projects) inexpensively, on spec and faster than any other firm in the pitch. It was more of a tag line, so there was little by way of explanation behind the claim. I held my tongue during the formal pitch, but made a point to ask the presenter a few questions after the meeting. Primarily, I wanted to know if he had heard of the triple constraint. The "iron triangle" as some refer to it, defines three pillars: cost, scope and time. It asserts that you have to prioritize the three with an understanding that trying to have all of them at the same time compromises quality. Some assert that several additional factors come into play when discussing a project's success. I agree with this, but I disagree with removing the triple constraint model from training, as I believe it's such an easy concept to teach, understand and enforce. My confidence in the triple constraint made it hard for me to believe that anyone had truly convinced themselves they could beat what is, essentially, physics. But sure enough, I got a very firm response from the organization: "We are able to deliver this service because we take an agile approach in our production processes, making us more efficient and thus able to deliver more value for the customer." Confused, I pressed a little further. "As I understand it, agile as a methodology does not allow you to overcome the basic physics outlined in the triple constraint. Agile simply prioritizes the tradeoff as one of scope rather than time or quality," I said. Of course, it wasn't a discussion I was going to win in this setting. Looking around, I saw that the speaker's entire management team had bought into the theory and were smiling proudly at their triumph. I let it go. But it struck me how much confusion still seems to be out there around the triple constraint and the ability of newer methodologies such as agile to overcome it. How many of you have had your management tell you to explore agile as a way to get your current project work done faster without sacrificing any of the three pillars? And how many of you still use the triple constraint to help you explain the basics physics around project execution? |
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. |
Where Project Management Rigor Meets Flexibility
Categories:
Nontraditional Project Management
Categories: Nontraditional Project Management
| In my last post, I described the challenges of maintaining project management rigor in an environment where people are primarily in creative service roles. It appears I hit a chord. A few of you have commented and want to know how I've handled the situation. Well, first I will say that I believe we will never reach 100 percent compliance with the project management standards you'd expect to find at NASA or a construction site. Creative work is not an exact science and it requires some very non-linear thought and approaches. It can be very hard to pin down a repeatable formula for executing these kinds of projects. If there are specific tasks you cannot predict or that don't fit into a prescribed methodology, people tend to simply operate by intuition. The first thing you need to do is to look for the wins. Where in the process can you continue to provide rigor and discipline to help keep the project within boundaries, while avoiding the appearance of overly constraining your teams? We have done this by creating as flexible a methodology as we can. As a whole, it closely follows the tenets set forth in A Guide to the Project Management Body of Knowledge (PMBOK® Guide). The software development life cycle serves as a foundation: planning, discovery, design, build, test, implement, support, rinse and repeat. The difference comes in our application. For any given project -- whether it's a marketing e-mail, interactive web banners, mobile applications or full site development -- we have fundamental requirements that don't change. All projects must have a timeline, for instance. And all projects must have a scope, a set of requirements approved and reviewed throughout to ensure we're on target. Beyond that, it's the diner's choice: Does a four-week e-mail project require a formal matrix of approvers? Probably not, though it would help to have a short list of final approvers. Does an interactive banner need a content matrix or a formal technical architecture? It all depends on what the team needs. How has your organization tailored its project management approach to account for the unique needs of its project teams? |
Project Management in Nontraditional Environments
| Some people see advertising as primarily a creative business -- antithetical to the rigor and disciplines of project management. But the complexities of today's marketing mix are changing that perception. Agencies and clients who spent the past century perfecting project management functions around print, broadcast and direct mail are being forced to readjust systems to the complexities and rapid-fire change of digital marketing. Two worlds are colliding. Digital teams view process as an essential science. The project manager is the team lead that everyone depends on for risk management, communication, client management, profitability and ultimate success. But traditional advertising teams tend to see process in a different light. They look to their account and creative directors as the team leads. The project manager, while important, often takes on a more administrative role, ensuring resources are in place, schedules are communicated to vendors and paperwork is complete. When I took on my first role as a manager of a project management office (PMO) for a large ad agency two years ago, the difference between these two worlds became vividly clear to me in a conversation with one of our creative directors: Me: We need to translate the client brief into a statement of work so we have a specific record of what we'll be delivering. Creative Director: We don't know what we'll be delivering yet. Me: Then we should meet with the client to understand business requirements and document them for sign-off. Creative Director: I know what the client wants, but I'm going to tell them what they need. Me: Then how do I budget resources, document our success metrics and track the progress of the project? Creative Director: That's your problem. We'll let you know when we get there. It was an eye-opener, to be sure. But eventually I was able to adjust my view of what the team was trying to achieve. I set a baseline process to create a flexible methodology that would allow us to pull in elements that were appropriate, and not commit time to requirements that didn't lend a lot of value. Some of these changes included a flexible, scalable methodology that allowed teams to pull in elements relevant to their process. This allowed them to: Have you ever been in a situation like this? What have you done to maintain rigor in your environment when the project at hand did not readily lend itself to the traditional project management processes? |
