Drupalcon Day 3

So, I didn’t recap right after, so I’ll guess at what my impressions were right after. I learned a lot about Drupal Project Management and Process Management.

It was very helpful to see how other companies do their project management… even if they weren’t using drupal their methods are so effective! So I was doubly happy when I found that our methods are very close to the methods. What methods you ask? Well they talked a lot about waterfall vs. agile development… the great debate. Where you start one task and you don’t start another until the previous is complete (waterfall) and agile where you start one task.. if you get stuck go work on something else… and do iterations of changes, tasks overlap in the timeline, etc. They say waterfall works great for old school sites with site maps and exact hierarchical structure. But realistically websites today (and especially dynamic sites built with drupal) are not hierarchical. Pages and articles link to each other in all different ways. There’s probably a primary and maybe a secondary navigation… but that’s it, the rest is a cloud. So it seems the best way to do this… (which we do, yipee!) is first stage planning, second stage design AND development. That’s right not design finalize and stamp of approval on design and then start development. We design and develop at the same time. That way while developing we say “hey, wait that doesn’t work the way we thought… it has to work this way… um, designer, can you change it so we can style it when it works like this?”. It goes through iterations of what works back and forth with designer and developer.

Another helpful tip, more interestingly enough… don’t show the client anything until the wireframe stage… don’t talk to them about content types, CCK, workflow and other drupal mumbo jumbo. It will only have them trying to speak your language (incorrectly) and create a communication divide. Talk to them in “real-world language” and then go back and talk drupal with your team. Don’t teach them more than they need to know… with the client less is more. Deliver wireframes to your client, deliver mockups to your client and deliver alpha site to your client. Never deliver an unthemed site to your client. We learned this one… it can terrify the poor client and they can lose trust in you. They don’t understand CSS and theming. All they see is something they didn’t want… whether it functions the way they asked or not! This was one minor mistake we had with our last client, but luckily the client didn’t overreact and only said uhh… can that all be on the same line and can’t that look like this? Which created extra time spent on communication and reassurance, but it could have been avoided… if we only showed the alpha and not the prototype to the client. If it were a different client it could have gone worse though… much worse.

Another interesting debate in these project management/process sessions was number of mock-ups or wire frames to show a client (as in different mock-ups or wire frames). Some people said you should only show one, the one the design/dev team agree on. Some said you should show many. I agree with showing many… but before I wasn’t convinced really in one direction or the other… though in practice we show many (3-4). Most times the design your team prefers (though maybe not unanimously) is not the design the client picks. But this isn’t a bad thing… because a client does not always know how to say what they need but they can point to it. You may not realize it when they pick the less desireable design but later in the process you will learn you did the right thing because the client picked it for a reason. When showing only one design, the client may be fine with it, but later may feel like you limited their choices and didn’t really hit on what they were looking for.