Project Management for Small Projects

When we work with some of our clients on smaller projects, one of the things we hear a lot of is “This is a small, quick project, we don’t need project management.” But they still want the project to run smoothly and as expected. So how do you achieve this without a full project management plan? In my experience, you can pare back a lot of what may be standard operating procedure on larger projects, but you need to keep what I refer to as my top 5.

Documented Requirements

You can’t move forward without know what it is you have to do! This needs to be documented so that all involved with the project can reference them and understand the expectations for delivery. For some small projects, I have seen requirements and estimates discussed in a phone call, and agreement to move forward with the project based on that phone call. Verbal delivery of the requirements should always be followed up with a quick email, or through shared online tools to ensure that everyone is in agreement. It is far too easy for a customer to come back and dispute what was delivered if it has not been documented.

Documented Assumptions

Those requirements we just talked about? I’m pretty sure they take some assumptions into account, and those also need to be noted so that everyone is on the same page. For example, maybe the overall timeline for the project is a week, but the client doesn’t get you access to their system until day 3. Do they still expect you to deliver at the end of the week while you think you have a week from that point? The assumption that system access will be available at the start of the project is pretty key to that delivery timeline, and needs to be stated clearly. What other assumptions is the client making when they claim this is a quick, easy project?

Documented Risks

Even if a full risk register is not used for a project, risks should still be discussed and noted along with the assumptions. And don’t think that just because something is a small project, that there may not be big risks associated with it. Right now, its summertime here and that means vacations. Does the client have a key team member scheduled for vacation soon? What happens if the project is not done before they leave, does it get put on hold, does a coverage person step in that needs to get brought up to speed? What about a project that is only adding a few fields to an enrollment application? If those are needed to quickly meet a deadline for enrollment, any delays could have a huge impact to the client. Identifying those risks help to keep the focus where it is needed on these short-term projects. Which brings us to…

The Triple Constraint

Every project, no matter how big or small, has constraints. The Triple constraint represents the standard constraints of Cost, Scope, and Time. A change to one of these items, will impact the others, so it is important to know which of these is the most important to your client. As the project deviates from expectations, decisions made on how to progress should be guided by the constraint that holds the most importance to the client. If a specific deadline must be met then Time is your top constraint; some decisions may need to cut scope in order to meet that deadline, or to increase cost and bring in additional team members. Of course, the client or sponsor needs to be the one making the final decision, but you want to present the best options for them based on their key constraint.


Last, but definitely not least, is consistent communication. Decide with your customer what regular communications are needed, and stick with it. Don’t delay with bringing up any issues that the team may be having in order to keep the customer informed. Even if an issue has not impacted the delivery yet, letting the customer know as early as possible will eliminate any surprises later on. Transparency in communication has always, and will always, be my top priority when managing a project. Getting information out to all necessary team members makes for better decision making and a more successful project.

So, whether you have a dedicated Project Manager on your team or your team lead is taking on these responsibilities, project success is the top priority. Are your top 5 tools to ensure success similar to mine? Let us know in the comments.

Drupal 8 – The New Stuff

After attending the recent Drupaldelphia camp in April, I wanted to revisit the recent changes that came about with the Drupal 8 release.

Many new features and changes

  • Core has many additions, including Views, a breakpoint module, multilingual content, CKEditor, and inline editing of blocks.
  • Drupal 8 now uses many parts of the Symfony 2.7 framework – HttpFoundation, HttpKernal, Routing, EventDispatcher, DependencyInjection, and ClassLoader. It also now uses a new templating framework called Twig. ex.
  • The new version has improved responsive design where images can now be resized based on breakpoints and the Admin has been redisned to work on mobile devices.
  • Configuration data is now stored in files, which makes managing configuration with git much easier, and that data can now be imported and exported.
  • The REST and Serialization webservices are now supported.
  • All Core modules can now be found in the Core folder. The modules folder can now contain modules instead of needing to access sites/all/modules.
  • New Fields are now available for Date, Email, Link, Reference, and Telephone.
  • Fields can now be added to Nodes, Blocks, Comments, Contact Forms, Taxonomy terms, and Users.

Drupal 8 also includes updates to Module development.

  • Modules are now a mash-up of old Drupal conventions and Symfony conventions. Porting modules from D6/D7 to D8 is possible but will take a decent bit of effort.
  • .info files are now .info.yml ex.
  • Module development now follows an MVC pattern and is more object-oriented. The General Controllers are placed in the lib/Drupal/[module]/Controller folder following Symfony guidelines so that autoloaders will work. Form Controllers are placed in the lib/Drupal/[module]/form folder.
  • Routing is now done by a routing.yml file.
  • Hooks still remain, such as hook_menu.

Additional information on modules can be found here:


Upgrading to Drupal 8

The suggested method for upgrading a D6 or D7 site to Drupal 8 is to set up a Drupal 8 site, then import the configuration and content, with some caveats. The supported migrations focused on D6 since it is now end of life. Drupal 6 supported migrations are Core, CCK, Link, Email, Phone, and ImageCache modules. Drupal 7 currently only supports migration of content, users, taxonomy, blocks, menus, and filter formats.

Upgrade Requirements:

  • Fresh install of Drupal 8 with the Migrate Drupal module enabled
  • Access to the Drupal 6 or 7 database from the host where your new Drupal 8 site is located.
  • Access to the source site’s files.
  • The Migrate Upgrade module installed and enabled on the Drupal 8 site.
  • Drush 8 (recommended)
  • If migrating private files from Drupal 7, configure the Drupal 8 file_private_path path in settings.php before running the upgrade.

Upgrade Outline

  1. Download and install the required modules. Remember not all modules have been ported to D8 and some have been split – for example, Block has been split into Block and Custom Block.
  2. Run the upgrade
  • UI-based via /upgrade URL is good for lightweight sites. This is useful for small site migrations, you fill in the fields and let the magic happen. You’re rewarded with a pretty report at the end.
  • Drush (preferred) is the only option for large datasets.
  • Drush migrate-upgrade to generate the migrations. You can configure for more control over individual migrations.
  • Drush migrate-import to run migrations for individual items, after migrate-upgrade has been used with –configure-only.

There are some gotchas to look out for when upgrading:

  • Views do not migrate and must be recreated.
  • PHP filtering has been dropped.
  • Many contrib modules have not been ported to D8.
  • A good bit of stuff is still missing from the D7 upgrade system.
  • D8 requires PHP 5.5.9, so older systems may require a PHP update.
  • A full list of known issues (many related to D6) can be found here:

If you’ve found other tricks or tips or gotchas with your Drupal 8 upgrade, let us know in the comments.