C H A P T E R  10

Planning and Managing a Drupal Project

by Amye Scavarda

Welcome! This chapter is about planning and managing Drupal web site projects. You've seen what Drupal has to offer, and you're ready to build yourself a web site.

Consider this chapter with a bit of measured enthusiasm: building web sites is harder than it looks, and I have lots of silly analogies for describing the difficulty. It's like trying to make a swing set out of an erector set, or like riding a rollercoaster without the rails. Get excited about the possibilities, but know that not everything will go smoothly. Building a web site in Drupal is also a creative process, because it takes thought, talent, and technical learning to meet the goals that you've set. The best advice for beginners is to remove any preconceptions about what's easy and what's hard. Just let yourself learn. Enjoy being a beginner.

This chapter is about laying out your goals, clearly defining what you need, setting yourself up to be able to tackle a large project in small chunks, and learning what you need to research to be able to finish. It's also about time management, a bit about project management methodologies to help keep everything running smoothly, and what a reasonable project plan looks like. I'll go through the various parts of Drupal that impact planning, what to be aware of, and what the biggest challenges are.

By the end of this chapter, you should be able to clearly define what it is you'd like to build and have a rough outline of what needs to be done where. You'll also understand the responsibilities of the project manager. Even better you'll have the ability to break those responsibilities down into manageable tasks and the tools to be able to complete those tasks.

The Role of Limitations

“It's not what you start in life, it's what you finish.”

—Katharine Hepburn

Limitations are a necessary thing to be aware of when you're planning a project. Setting the expectation that you're awesome and that you'll have a fully built community site by this time tomorrow is great, but it's unreasonable. It's better to know your limitations, because you know what you can commit to in a reasonable amount of time—that's where the real awesome comes in.

Knowing how much time you have to devote to a project is the first step, so that when it looks like something really big is coming, you have clear boundaries around what effort you can put in and still stay sane. This is popularly referred to as “work-life balance,” but it's really about being able to maintain the systems that maintain your own productivity. If you haven't set aside enough time to be able to keep up with your own e-mail, personal connections, and laundry, you won't have a life while you get this project done and it won't be fun for anyone.

It's possible to have a site up and running in about 60 minutes, but I usually schedule 4 hours of time for an initial site build. I want to make sure that I can get the development hosting environment right, get e-mail (Google Apps) and SMTP servers set up, the DNS servers pointing at the right place, the Drupal install done, modules installed, a theme applied, and some content up.¹ While these tasks can be broken up over several days with an hour or so here and there, I find that I lose track of what I need to do next. A fully functioning site with working e-mail and some placeholder pages gives me at least a place to start.

Putting Down Your Concept on Paper

Once you know how much time you can devote to building your site, think about what kind of web site you want to build.

Here's what I think of as the 1 to 10 scale of difficulty:

1. is “I have an idea for a web site, but I haven't totally decided on the concept”. (Also known as “I'm going to install Drupal on my own computer and play with it.”)²
2. is “I have an outline of what this web site is, and I might have an idea of what the title is. I have a domain name registered.” (This is the bare site build that I'd budget 4 hours for.)
3. is “I already have a site that I built a long time ago in Dreamweaver/Publisher, but I can get the content out in straight text files. I don't want to improve it this week, but I'd like to migrate to a new site.”
4. is “I built my site a long time ago, and it has a lot of content that I want to move, like a photo gallery or all of my blog posts going back to 2001.”
5. is “I have a site that I need to migrate, and it had a custom design. I'd like to recreate that in this new system.”
6. is “I have an idea for a new community site, I'm going to have some users, and I'll start with some content.”
7. is “I want a new community site. I have lots of content that needs to be served dynamically, I'm going to have a lot of users, and I want them to be able to do six different things to communicate with each other. “
8. is “I have a community site already. I'd like to move over all of the content that I have now. I'd like to move over all of the users that I have now. Also, I want to add mapping, geolocation, feeds from different sites, and private messaging.”
9. is “I have three different sites that I want to move over to Drupal. They all need to work with the users I have now, but I don't want to change any of the passwords. Users are going to be able to interact with each other in 10 different ways. I have a lot of content now, but I don't want to move over all of it, so I need to decide what to move and what needs to be recreated in the new site. I'm also tired of my current design, so I want to do something new.”
10. is the same as number 9, with the addition of “I need it to happen in three weeks. Or maybe yesterday. Can I build this today?”

_________

These are just some rough sketches; there are thousands of different examples for each category. My hope is that you won't try to tackle anything above a 6 on your own. I deliberately left out “And I'd like to be able to sell things on my site,” because adding a store generally pushes any of these projects up a notch in terms of complexity. So it's possible that this scale goes to up to an 11, but anything above a 5 will usually require more than one person's help, and anything above a 6 will require anywhere from 3 to 10 people's time and input.

If you have an idea of what you want to do, start taking notes about what category your idea might fit into. What's the purpose of your site? Who's going to use it? If you're having trouble narrowing it down, try thinking about what it isn't. This is your brainstorming space.

Before I get too deep into the brainstorming, take a look at Figure 10–1, which shows what the lifecycle of web site development looks like.

Figure 10–1. Lifecycle of a project

The difficulty scale takes this lifecycle into account. A site that's going through the first phases will be much less complex than a site that's moving through the fourth iteration. Sites that are more established are not starting from a bare idea anymore; they have established content, or established users, or they're moving from a system that isn't fitting all of their growth needs anymore. Consider that your project, too, may need to grow over time. Drupal is pretty good about accepting input from a wide variety of sources and outputting information in a wide variety of formats. It's flexible, but it's just a tool to put your requirements on paper. Let's walk through the project lifecycle using the stages in Figure 10–1.

1. Discovery

If you're just starting out, you're in the discovery phase: What do I want? What does it need to do? What does it look like? Who's participating in this project? Who are the decision makers?

Project plans come out of discovery; these plans inform the rest of the lifecycle. They're the guiding documents that help determine the scope and schedule of the project.

2. Information Architecture

Information architecture is about taking those brainstorms and putting them down concretely. Wireframing lets you build a prototype of what information the pages will contain. Think of it like the blueprints for a web site, just like an architect draws plans for a house. Figure 10–2 is an example of a video site wireframe created in GoMockingbird. (http://gomockingbird.com).

Figure 10–2. Example of a wireframe

This lays out information on the pages. There's a title for the whole site, which could also be an image. There are login and signup links, which means that there are users for the site. There's a search bar and links to Facebook and Twitter. There's a main content area where videos and text live. There's a sidebar for related content. This wireframe provides a visual reference that the designers can work with without having to recreate a web site from scratch.

Another part of the IA stage are functional requirements. Functional requirements are meant to capture all of the features that the site needs to have and what it needs to do. Functional requirements are not the “how” but rather the “what.” If you're able to answer what needs to happen in plain English, that's the start of the functional requirements.

3. Design

Once you have the wireframe of where everything goes, the design stage puts clothes on it, adding a look and feel. Colors, fonts, how the site will look—it all happens here. After the design is complete, it will look like a web site, but it'll be just a Photoshop file. Warning: there's the expectation that anything that can be done in the Photoshop file can be exactly matched by the web site. Sometimes a Photoshop file goes beyond what's possible. Expecting an arrow to be exactly 3 pixels away from the link will lead to disappointment in the end. Changing the expectations to reflect that there will be an arrow next to a link is much easier to fulfill.

4. Development and Implementation

If the functional requirements are the “what”, development and implementation (along with the timeline and project plan) are the “how.” All of the things that you said you needed—this is where you decide how long it'll take and who's going to make it happen. This is where the wireframes get put into an actual working site, the design gets added, and the site starts to look like something that you'd see in your browser. But there's still something missing.

5. Content

The soul of a web site is content: stories and photos and videos. This is the stage of the project where you add the content. It's also leading into the quality assurance phase where you make sure that it works like you expected it to and it looks like you expected it to. If it doesn't, you either fix it or change your mind about what you need.

6. Deployment/Launch

Your site is completely done. It's ready to go live, but if you're doing it right, you have two separate environments: one for development that you can tinker with, and one for production that is the site the world sees in a browser. You'll need to migrate everything from the development site to the production site. This takes a bit of time and work.

You also need to check all of your work. Do the links work correctly? Did you remember to turn on the automatic path creator when you were adding content, so that /node/X isn't the URL? Did all of your images move over correctly? Did you lose the files directory in the migration? Is the theme working correctly for IE6/IE 7/IE8, Firefox, and Safari? Check your views to make sure that they're formatted correctly and display what you want. Did the favorite icon on the top of the URL bar in the browser get lost? This is also your chance to test multiple user roles. Can an anonymous user see things you didn't intend? Check and make sure. Keep a spreadsheet handy and note everything you need to change before you change the domain to point to your new site.

7. Maintenance

Your project will probably need updating as it goes along: modules get updated, Drupal core gets security updates, and new versions of Drupal come along. Eventually, you'll want to take advantage of new features or a new design, or you'll want to change the site entirely, and so the lifecycle will begin again.

Project Management Methodologies and Drupal

The lifecycle phases get documented into an overall project plan, and that project plan is also directed by methods to help you succeed. There are a few ways to think about this and some project management methodologies to touch on here. Drupal has adopted two basic methodologies: the more traditional “waterfall” style and the more iterative “agile” style.

Waterfall comes out of traditional project management. The planner assumes that there are a finite number of tasks, however large the list of tasks list may be, and that each of those tasks can be put in a sequence to bring the project to completion. Every task is estimated and known ahead of the start of the project. This style is usually used in large construction projects or projects that have a very concrete deliverable at the end. Waterfall also usually works off of an exact budget or an exact timeline. For example, when I'm planning an event, like a conference, I tend to use waterfall as a guiding principle to keep everything on track. I know that I can't adjust the timeline, so I do what I can do within the timeframe and make it work.

Agile is an iterative process for planning your projects. It assumes that you don't have as much knowledge about the finished deliverable. It's a collaborative process with all of the people who have a stake in the project. It emphasizes teamwork in planning, short bursts of development, and feedback at the end to adjust the project goals. I tend to use agile when I have an internal project that doesn't have billable hours attached to it or a project that doesn't have a very firm deadline. Agile works well to kick off a project that doesn't have enough information to let waterfall be effective; however, agile isn't helpful when trying to finish a project that has a set launch date, a concrete budget, and many required features.

Knowing both of these approaches is useful, because a Drupal project benefits from a combination of the two. In Table 10–1, I've broken out the tasks into tasks that benefit from a waterfall approach and tasks that benefit from an agile approach.

Table 10–1. Waterfall and Agile Breakdown by Drupal Project Stage

	Drupal Tasks That Use Waterfall	Drupal Tasks That Use Agile
Discovery	Documenting the project plan, timeline planning	Brainstorming
Information Architecture	Functional requirements	Wireframes
Design	(Very little about design work fits with waterfall)	Creating design layouts
Development	Only on a high level matching of functional requirements	Building out all of the features in a site, creating the site.
Content Staging	Deciding which content is added	Active work works best in sprints
Quality Assurance	Matching with functional requirements	Not as effective
Deployment/Launch	Checklists for launch	Not as effective
Maintenance	No methodology preference	No methodology preference

In general, if the project has a lot of uncertainties, agile will make for a better end product. You're better able to add more features later on in the process as you get more familiar with the project and its needs.

Waterfall will allow you to sketch everything out ahead of time, leaving very few uncertainties. You'll know when you're launching, what your minimum viable product is, and how much it'll cost. As you become more familiar with the project, you may not be able to take advantage of some brilliant thoughts without changing the scope of the project.

Site building and implementation is where “agile-fall” comes into play. Your team will probably work better in a focused agile environment to complete tasks, but your client may not be comfortable with watching agile happen. The project manager can lay out the lifecycle in a waterfall style (I'll be done with X by this time) but manage the team's work through agile user stories. It makes development and project management a lot less stressful if you don't have to explain how agile works at the same time as you're trying to discover what a client needs for a project.

Taking the Lifecycle into Account on Paper

You now have a good idea of what you're building and a rough idea of how to structure it. Now you need to answer these questions:

• Why you are building this?
• What it's going to do?
• When will each stage of the cycle be complete?
• When did they need to be completed?
• What needs to happen within each phase?
• Who's going to do this?

Understanding the complexity involved is helpful. This will all come together in the project plan.

What's a Project Plan?

A project plan is a document that speaks to the purpose and methods of a project. It defines what's at stake in the project, who the main stakeholders are, the scope of the timeline (as well as what that timeline is driven by), and the outcomes of the project. It also breaks down what happens in what order and who's both responsible and involved for each phase. It is a client-facing document because it's designed to create alignment between everyone involved. When a project plan is complete and clear, everyone knows why this project is being done, what sense of urgency is attached to it, and when the project is potentially launching. When it's done right, a project plan doesn't gloss over the hard parts: how difficult the project is, how fast it needs to be done, and who's actually committing to making it happen.

Purpose is a distinct part of the project plan, although it can be no more than a few sentences. With a startup, it can be: “This is the public face of our new start-up. We want to show off what we're working on and get our first sale.” With a larger, more complex project that's migrating from an existing platform, the purpose can be: “We want to update our web properties to take advantage of a new level of customer engagement. We want to be able to have more satisfied customers and more sales.” For a community site, “I want our users to find content that is relevant to their needs.”

The purpose statement should be written in plain English: it articulates the goals of the project. Print it out. (Yes, a dead tree.) Keep it around for tricky meetings—those meetings where everyone comes to the table with something they're invested in seeing happen for the site, well after the scope has already been determined. This purpose statement can also be used to answer questions such as “Does X idea help fulfill our purpose? Is it worth changing the scope to incorporate this?” The purpose statement will help keep your project on track.

Example Project Plan for BeachHouse Non-Profit

Mission: BeachHouse is a nonprofit that wants to update their web properties to take advantage of online event management and donations.

Features:

• Static pages that are easily updated by non-technical staff
  • Images on pages
• Documents available for download
• Donations
• Events
• Email newsletter signup
• Photo gallery for past events

Timelines:

• Week 1: Kickoff, discovery, and planning, June 18 - 25
  • Kickoff meeting on Friday
  • Project plan and review on Monday
  • Layouts for home page, internal site pages
  • Thursday meeting: Theme discussion with site view, layout review
• Week 2: Initial site build, June 28 - July 3
  • Monday: choose theme
  • Site map for content
  • Feature review
  • Content strategy overview
  • Content types documentation
  • Roles documentation
• Week 3: Alpha site build, July 5 - 9
  • Monday: Themed site up and running
  • Wireframes for landing pages built
  • Content types built
  • Feature functionality built
  • Initial roles and permissions built
  • Thursday: review
• Week 4: QA, July 12 - 16
  • Monday: Review of site map
  • Content staged by development for landing pages
  • Content types, roles, and QA
  • Donations tested
  • Thursday: Review
• Week 5: Content Staging, July 19 - 23
  • Monday: Site review with available content
  • Content staging
  • Content checklists
  • Thursday: review
• Week 6: Beta Site, July 25 - 30
  • All content complete for launch
  • All QA completed
  • Site launch on Thursday, July 29
• Week 7: Post-Launch Support, August 1-7
  • Training screencasts reviewed with staff
  • Support time
  • Maintenance contract discussions

Estimating Completion Dates

Remember: Dates in Calendar Are Closer Than They May Appear. Be careful; allow yourself a reasonable amount of time according to what you've done before. In an ideal world, it might be possible to turn around a fully themed, content-complete site in less than two weeks. A site that will involve a lot of custom development or one that requires migrating from a legacy system will require more time.

To start with, go through the lifecycle on paper. How much is there to discover? Will you have to spend a week of active work reviewing the legacy site before you have a good idea what's there? Does the client want a very complex design? Plan for 30% more allotted time for a few revisions of design. Are the features they want something you'd heard about someone else doing? Have you installed those modules on another site? Your development estimates will be much lower if you don't have to build modules from scratch, but leave time for configuration. Estimating your time is a major part of succeeding at projects and keeping everyone satisfied with the pace of work.

What Happens If I Don't Do Anything?

Be willing to raise this question in the planning process. When the purpose is defined, it also raises other possibilities. If your community site doesn't have content that resonates with your users, what happens? They might never come back and you could lose your advertising revenue and go out of business! It's possible, so you should be sure that you're doing the absolute best thing you can be doing for this project to support the business behind it. The answer may be that you shouldn't do this project until X is in place. If a project isn't set up to succeed, it won't, and there will be many awkward conversations. I guarantee it.

Risks

One of the biggest risks in a project is the integration/migration of the old system with current systems. This problem is usually compounded by the need to have the new site done yesterday in time for x event or y publishing event or z holiday. Whenever possible, those hard deadlines need to be known and factored into the plans. However, ours is not a perfect world: things happen and hard deadlines don't get met. For those deadlines, defining a minimum viable project is critical to maintaining the relationships.

When everyone knows what the minimum is, they know how bad it can be. It can also sometimes have the opposite effect, turning the project's deliverables into a “race to the bottom,” cutting down on deliverables until the minimum amount of work is expected. It's the project manager's job to hold both ideals: the amazing web site project that was created in sales, and the bare bones version that will meet the client's needs, if not their expectations.

Minimum Viable Project/Product

This is the bare bones project that will meet the purpose of the project. This will probably not meet everyone's expectations for features or designs or both. For some projects, the MVP can be a domain name with a simple splash page featuring a logo and a color palette; it's a version of a “Coming Soon” page or the “Under Construction” icon.³ Or it can be a newsletter signup or a contact form that gives the wider audience an opportunity to engage with the project, a series of static pages that speak to the project's mission. Think about the minimum that needs to be available at a given date when there's no engagement from the client, when the development team has been stalled by a tricky problem, or there's a change in the main stakeholders of the project. Laying this out in the project plan helps set the expectations of what's needed versus what's wanted; it's crucial to laying a foundation for expectations. Define this at the beginning, and then it's a question of being able to build up from it or scale down to it.

Keeping Track of Commitments

There's an estimated completion date, the milestones have been laid out, and there are clear deadlines. Something else is missing: the tracking/ticket system. This system needs to be something that will hold deadlines and help manage accountability for the entire team—including you, the project manager. It needs to track milestones and tasks against dates, and have a way to change the status of a task. It's also useful if it has a reminder system through e-mail or SMS.

Here are some personal favorites:

• Unfuddle
• Basecamp
• ManyMoon
• 5pm
• LiquidPlanner
• Teambox

__________

Note that none of these are Drupal-based task management systems. This list is about being able to manage large and small projects with ease. A system is for peace of mind, and the ability to manage more than one project at a time. When something is added to the ticket system, it's visible to the entire team that's working on it. Nothing is forgotten in an e-mail inbox somewhere, and there's a record of what's happening when.

So from this point on, everything is about putting this project plan into action. I'll let you in on a secret: you've already done a lot of the hard part. The build is not all smooth sailing, but you now have a road map.

You're now the project manager in charge. It's your main task to keep everything else organized, working on the right thing at the right time, and making sure that everything finishes when it's supposed to. You're also going to be the main person who communicates with the people who matter to the success of the project. This may be the people who are sponsoring this new web site within your organization, or the people who are paying you for it, or even Mom and Dad, if you're building Mom and Dad a blog. You're going to have to be able to ask questions without expecting the answers, and you're going to have to translate Drupal-speak into human language. On a good day, it's actually a lot of fun.

I'll lay out most of the events of a project manager having a good day, so that you'll be able to have more good days and less bad days.

Project Manager Tasks Beyond Development

The project manager's job doesn't end after the project plan. You're now in charge of producing the project through kickoff meetings, design meetings, check-ins, and milestone closing meetings. This is the “Day in the Life of a Project Manager.”

Kickoff Meetings

These are the meetings when introductions happen, when all of the team gets to see each other for the first time. Finding out who's filling each role on the team is critical, and I find that face-to-face meetings have a much better outcome over the whole life of the project. This is a relationship-building time where everyone makes sure that they're talking about the same thing. Some terms might come up that people don't understand, so here's a quick glossary of some words I use when I talk about Drupal in a project kickoff meeting:

• Wireframe: The nonworking prototypes for what a site will look like. It's a skeleton.
• Mockup: Photoshop or other files that take the wireframe and add a look and feel to it. It looks like a full site, except that nothing works.
• Layout: How information (graphical or otherwise) is laid out on a page.
• Concept design: Another term for mockup.
• Theme: A set of files that change the look and feel of a web site. This is where design is involved.
• Module: Pieces of functionality that can be installed into Drupal. It's the system of interchangeable parts.
• Features: A set of files for Drupal that combine the functionality of a lot of different modules into one. It's sort of like interchangeable engines over interchangeable parts. However, the word “features” is also used to describe the simple functions of a site.

Design words for Drupal are more difficult because design is usually the only part of the site that most non-technical people can touch. You can see it, you can describe it, and it's something that you're comfortable looking at. Expect kickoff meetings to usually run about an hour or two. You'll be discussing the project plan, timelines, and resources for the project, and agreeing on any modifications.

The questions that everyone will want answered include the following:

• What are we building?
• Who will be working on it?
• Who's responsible for which part?
• What's the project cost?
• When will it be done by?
• Bonus question: What's driving this project?

Ideally, this will not be the first time that everyone in the project will have thought of these questions, but by the end, you should have the same answers.

Discovery Meetings

These are the brainstorming meetings. They're unstructured; there isn't a whole lot of deciding that goes on in these meetings, but they're integral to the success of the project. Documenting what comes out of these meetings is challenging, but it's invaluable to the designers as they put together concepts.

The following questions get answers in these meetings:

• What are some other sites you like?
• What features do they have?
• What do you not like?
• What message do you want to convey through design about your site?
• What are some examples of this that you've seen on the Web?

Know your own abilities here, so that you don't promise to implement the latest Facebook redesign for your first Drupal site. It's easy to get carried away with design, so be careful. Prioritize features over design if at all possible.

Information Architecture/Design Meetings

These meetings usually involve a deliverable of a wireframe or a concept design. They're meetings with the project manager, the information architecture expert, the designer, and the clients. It's a discussion about the features and what needs to be added, removed, or changed. It's also a conversation about the look and feel of a site: too light, too dark, wrong treatments, more rounded corners. These meetings are better if they're short (30 minutes) and frequent (twice a week) until the IA expert and designer have reached their final drafts.

The following questions get answers in these meetings:

• Is everything where it's supposed to be?
• What's missing?
• Out of these three designs, what elements do you like best?
• Is this the final design, or do we need another round of revisions? Based on the estimates, we're X dollars through the design phase. Adding another round of designs will increase the budget of the entire project by Y. Is this something that you want to do?

This is where budgets will start to get pinched. Watch carefully and be transparent about what resources are available.

Development Meetings

These meetings are usually internal between the project manager and the developers. They lay out what's been done, what's left to do, and what's blocking things. In agile, they're held daily and they're very short—no more than 20 minutes. These development meetings help coordinate the development team, make sure that everyone else knows that progress is being made, and can jointly solve problems. These meetings happen through the life of the project.

The following questions get answers in these meetings:

• What am I working on?
• What's next?
• What things will be/are a blocker?

Checkins

The project manager is the one that goes back and forth between the developer team and clients to make sure that questions are being answered. This requires translating between development and the client; the content will change depending on what phase of site building is occurring.

The following items are covered in these meetings:

• This is what we are working on.
• This is what's coming next
• What do we need your help on?
• How's your content coming?

Milestone Closing Meetings

As a phase of the cycle gets closed, the project manager, lead developer and client meet to make sure that everything that needed to get done during the phase has been completed and that the next phase can begin. If any changes need to be made, they should be small, or this will also turn into a change of scope conversation.

The following items are covered in these meetings:

• Here are all of the tickets we closed in this project.
• Here's where this is on the development site.
• Does this need to be added to the next phase, or is this complete?
• If we change this, it will add X amount of time to the project. Is this OK, or what else needs to be dropped to make this happen?

Launch Meetings

The final meetings before launching the site are when all of the developers, the project manager, and the client get together and discuss any final changes before the site goes live. If communication has been good all along, there will be no major surprises in this meeting. If something has gone awry, this meeting can bring up unpleasant surprises. As the project manager, you need to match any requests in this meeting with the functional requirements document. If it wasn't in the functional requirements document, it shouldn't be on the table for this particular meeting; it should be pushed out to a future phase of work.

The following items are covered in these meetings:

• Everything is done according to what we talked about before.
• What small changes need to be made?
• All of our content is here accurately.
• We've tested our work on the production site and we're ready to take this project live.

Post-Project Debriefs

Sweet! The site's live, everyone's happy, and now the team can sit down and talk about what went right, what didn't go so well, and what could be changed. This is usually an internal design/development/project management meeting because candid feedback is the main goal of this meeting.

Other Tasks for Project Managers

Outside of all of these meetings, a project manager has real tasks beyond tracking what's going on in a project. The project manager helps to create clarity around what is happening and why.

Creating User Stories

One of the best ways to know what the expectations are for your project is to break the scope down into a series of stories. What should a user be able to do? What kind of things should an administrative user be able to do? These are larger stories that tell concrete things, not a series of tasks. They will probably be written throughout the project, not just at the beginning. They're easy to take to the entire team as an explanation of what each element needs to do.

Here are some structures for the user stories:

• I want to [do something] with [x part of site] so that I can [reason]. Example: I want to be able to bookmark things within my profile so that I can find them again.
• As a [role], I want to [goal], so that I can [reason]. Example: As an administrator, I want to delete comments on a post so that I can moderate my site's user-created content.

A traditional agile workflow has these stories written on small cards: story, some concept, and confirmation that it works. These three things have to be present so that any single team member could complete this task without being dependent on another card being completed. It's a great ideal. More often, teams aren't big enough to need this sort of interchangeability, so these user stories serve as reminders for what complete features look like within a site.

Implementing Tasks and Task Workflow

Out of user stories, you'll need to create tasks. Tasks are small concrete things that need to be built/done/taken care of, and they integrate into a full workflow. Most ticket trackers can support this: a task can be in different workflow states.

A task will start out as “new” and will move to “assigned” after it's been assigned to a team member. That team member can “accept” that task if they feel like they have enough information to complete it. The task can also be “rejected” if the team member feels that it needs more clarification or shouldn't be done right now; the project manager and team member should discuss it with the whole development team or the client.

When a task has been completed, it will move to “resolved,” and then it's the job of Quality Assurance (QA) to test it and confirm that it works as designed on a variety of platforms.

A task can be “closed” when there's no further action needed, or QA can “reopen” the task if there's something that needs to be changed. QA can report bugs back to the PM and development team.

It's helpful to have a separate bug tracker that isn't in the same space as a development workflow. The actual workflow is the same, but a different system allows for separation of development and fixing. Giving a client access to the bug tracking system (not the entire development ticket system) is helpful to move the project forward because it is easier to ask for and receive focused feedback.

Tasks are not always all in development. Design tasks can be to create Photoshop mockup for BeachHouse or create HTML/CSS layouts from approved mockups. Project management tasks can be to create project plan or populate discovery milestone with tasks. Tasks are assigned to milestones, with all of the estimated times for each task added together to create that milestones.

Tasks That Make up Milestones

When all of the tasks in a milestone are completed, the site can be reviewed by both the client and the project manager for approval. There's usually some time built into the project timeline to account for necessary review time before the meeting.

It's helpful for all sides to see what was accomplished, what's working, and what's left to do. These milestone sessions are also a good time to review the budgets. Ask the following questions:

• Based on the amount of work that's already done, how are our budgets looking?
• What's left to complete in the project?
• Do I have the budget for the next phase?
• If I don't have enough budget, what can be cut to make this work, or how do I get more budget?

Take the time to review and prioritize the next steps, and be honest about the project scope and the budget.

This can also be a time where things get added that weren't originally in the scope. It's the project manager's job to keep the original agreed-on scope in mind, manage the budgets to be able to meet the expectations, and get the project completed. Reviewing the scope before each milestone meeting is the best way to keep on track, but it's a struggle. The project manager has to set the tone; the best way to do this is to remain consistent throughout the entire project.

Bad Days

All of the above events and tasks happen as a normal part of a project manager's life. A bad day is when pieces of your project break, aren't meeting the expectations of a client, or are pushed aside entirely and forgotten.

You're the keeper of the relationships in all of these projects, and while it's your job to make sure that the project gets finished, sometimes that also means putting egos away and having the tough conversations.

Tough conversations include:

• “I need more communication.”
• “I need more focused communication.”
• “I've already talked about that, and we said we were done.”
• “This is what it will take to change course.”
• “We're out of budget.”
• “I can't implement that design.”
• “We're behind schedule.”

Having the tough conversations is no fun, but not having them is worse in the long run. Don't let this happen to you! Take a deep breath. Be willing to have these conversations when necessary. Document what you needed to do, how you did it, and the outcome. Every conversation can be handled in a way that gives a good outcome for both parties. A good template is:

• What happened
• Taking responsibility
• Your team promises to do X by Y
• What happens next

Be willing to take a few hits for the team. Promises will get broken. Tests that should have happened won't happen. Designs that should have been delivered won't be. Content that should have been added won't be ready in time. E-mails will land more harshly than intended in stressful moments. It will feel awful.

If you can, let the rest of the team in on those calls/meetings. Let them watch how you handle the failures of your team without making it anyone's fault, how you take responsibility, how you manage the breakdown in communication, how you restore trust with the team, and how you help the project move forward.

In the end, the best projects are the ones that have the teams that understand each other the best. If you can communicate the goals of the project to different personalities, you'll have a much better time. You'll also need to recognize various skill levels in every project, including your own. You're not only a project manager; you're a coordinator, leader, and mentor.

Have fun!

Further Resources

Managing Humans by Michael Lopp http://managinghumans.com

Making Things Happen by Scott Berkun www.scottberkun.com/books/making-things-happen/

Becoming Agile: In an Imperfect World by Greg Smith

More about Managing Budgets from a Drupal Project Manager - affinitybridge.com/blog/managing-budgets-and-billing-while-practicing-agile-development