How we work with clients

How we work with clients
0

As a remote team working with remote clients, our system of project management is critical to our client’s, and our, success. This topic describes the elements and operation of our system of project management.

We are constantly updating our system based on our experience working with our diverse client-base. If you have any thoughts, or questions about our system, feel free to respond in this topic.

Categories, Projects, Tasks and Members

Every Pavilion client gets its own group and private category here on thepavilion.io. Access to each client category is granted to the the client’s group and the Pavilion members working with the client. All work with the client is managed through the client’s category.

We try to avoid using email, chat and even video calls if it’s possible. We are true believers in both Discourse and our open source plugins and themes that are part of our use of Discourse as a project management system, and always prefer to use Discourse over other mediums. You can read more of our thoughts on this here.

Within a client’s category, work is broken down into “Project” and “Task” topics. A project is a specific desired product outcome, like “a new landing page”. Tasks are the work required to implement a project, such as “Implement the structure of the landing page design”, or “Implement the universal search bar at the top of the landing page”. The role and scope of both of these elements will become clearer in the sections below.

As for the Pavilion members assigned to a client, there is always at least one member with a Project Management (PM) role and one member with a Development (dev) role. This may be a single member with both roles. These assignments may change over time, however as much as possible we try to keep the same members assigned to the same clients to reduce the transaction costs and knowledge-loss associated with switching members around.

1. Initial project specification by the client

After Client Onboarding, the first substantive step in the project management process is that a client provides an initial project specification in a new topic in their category on thepavilion.io. If the client provides this initial specification verbally or by email during their initial interaction with Pavilion, before their category is established, this is copied or transcribed into a new topic by the client or a the PM member assigned to the client.

This initial specification contains as much detail as possible on what the client wants to achieve. Visual mockups, text descriptions and any other tools the client wishes to use to convey their desired outcome are fair game here. We encourage as much detail as possible at this stage, particularly assumptions about how the product outcome of the project will work in practice.

Here’s a real example of an initial specification (the client’s name has been removed, so the links to examples will not work):

Initial Specification Example

We have a jobs and gigs posting section of community.example.com. In order for people to posts jobs and gigs, I’d like to have a webform to ensure they fill out specific information. And then ensure that info is displayed in a consistent way.

There are two types of posting, jobs and gigs.

Job Post

Phase 1. Currently, when user fills this out, they are pushed to their new (hidden) topic and I’m sent an alert that they posted. Once the UI/visual issues are resolved below, I’d go live with this.

Phase 2. Chargify integration. It would be awesome to have functionality that – after filling out the form – sends the user to chargify to pay for the post. That chargify step would carry over information about the post, so we know what’s been paid for and what hasn’t.

After payment, send user to Thank you for posting - Jobs and Gigs - Example Community

  • We have the chargify forms already set-up, but you’d need some information to setup this integration.

Gigs Posting

We will also have a separate form for gigs posting. The gigs form will be similar to jobs posting, with distinct form fields. The gigs posting wizard will also be connected to chargify, but to a different checkout page.

Current issues with UI Elements

  1. See below, do you know how to make sure our Example icon appears in the bottom-left box? Currently it’s a blank square. I’d love the image used here to be one of these
    https://staging.community.example.com/admin/site_settings/category/all_results?filter=logo

    This might have been solved with a recent discourse update

    1d81d3137bd0d76b9d46113b94191065335482c7

  2. Right now this box appears to be limited to about 700 px height (not sure specifics), and this cannot increase or decrease. I’m curious if we could have this change as, for example, we add more fields to a step, or as a text area expands in size?

    This isn’t so important for the job and gigs board, but will be really important for all the other form wizards I’d like to set-up.

    f96a7a70a93defd2cd14514567c723f405c8c57c

Gigs post

Gigs will have a similar setup, but with different form fields, and link to a different chargify option.

Project 2 - Embedding a Marketo Form into a discourse page.

Note: There will be dozens of these forms, each linked to a different marketo form, and with different text around the form. So some thought to setting this up as a reusable template would be helpful.

  1. Users are directed to a special URL, e.g. community.example.com/w/{form-name-01}

  2. If the person is not logged into the discourse form, the are prompted to login, or create a new account.

    • Currently, with wizard forms, if the user is not signed-in, they are just given a “Oops! That page doesn’t exist or is private.” message.
    • The discourse feature that supports composing a new (pre-filled) topic via URL handles this quite well. Note if you access a discourse site via this pre-filled new topic URL via incognito/private mode, you’re first asked to log-in or sign-up. Once you’ve logged-in, you directed back to that pre-filled form.
  3. That landing page would have:

    • Some text, markdown formating. (e.g. title, text, images). It would have information similar to this , but limited text/image/formatting options (e.g. those of a discourse thread) are totally fine.
    • The page would also support a marketo form. Either embedded, or sending form-field values to markeo.
    • Example and test form field
  4. Special Ask (but this is low priority):

    For example, if the URL given out was https://staging.community.example.com/w/ide-bug?utm_medium=social&utm_source=fb_paid&utm_campaign=buffer91838, then …wizards/submissions/ide-bug would log those utm_campaign and utm_source fields.

    Fields to log: utm_medium, utm_source, utm_campaign, utm_content

  5. Once you complete the form, you’re redirected to a URL. Likely “thank you”
    Resolution: just add a “thank you” page to the form.

2. Project Development

Once the client has given as much detail as possible on their project, the Pavilion PM member assigned to the client then works with the client to distill, scope and clarify the the project, with a view to the nature and scope of Discourse-based projects.

In working with the client to develop the project, PM member considers

  • the client’s budget;
  • the client’s priorities;
  • the nature of the client’s community;
  • best practices in community product management; and
  • best practices in Discourse development

There is often a difference between a client’s initial conception of their project and what is ultimately settled on between the client and the PM member. An initial project specification is often broken up into multiple projects.

3. Task Development

Once the project specification is settled, the PM member then breaks it down into individual tasks, each with their own topic, again with a view to the nature and scope of Discourse-based development.

In the task topic the PM member will describe each task in terms of technical outcomes. They will also estimate both “billable hours” and the “days to completion” for the task.

  • Billable hours are:

    • the number of hours the PM member applies in structuring the projects and tasks within the context of Discourse-based products and software development. Typically this is a couple of hours, but can increase in particularly complex projects.

    • the number of hours it will take a developer with expertise in the subject matter of the task to complete the software development portion of the task.

  • Days to completion is an estimate of the number of actual days the task will take to complete. This factors in various things including that

    • developers are assigned to multiple projects at once;

    • it is often more efficient to break up work, particularly if a problem is encountered; and

    • other personal excigencies.

4. Quote & Contract

Once the project and the tasks are settled between the client and the Pavilion PM member, the PM member provides a quote for the implementation of the project. For a description of how we determine quotes see:

Once the quote is agreed, we sign a contract with the client containing the specification and the quote. For a description of our approach to contracting see:

5. Software Development

Once the quote is agreed with the client, the PM member assigns the individual tasks to the Pavilion development members on the project, sets due dates for each task based on the “days to completion” estimates, and an overall project due date based on the combination of the task due dates.

Development work then commences on the tasks. The Dev member assigned to a task will give regular updates on the progress of the task, including:

  • Raising any unforseen technical challenges that will cause the task to take longer than initially estimated. The client may either change the specification to allow the challenge to be circumvented, or agree to an increase in the billable hours on that task.

  • Raising any technical decision-points that the client may be interested in, including decisions that may affect:

    • future projects or goals of the client for their community; or

    • the stability of the work over time (i.e. how likely it is to be affected by changes to Discourse and other dependencies).

6. Testing and Demonstration

Upon completion of the development work, the work is deployed to a staging instance (either the client’s or Pavilion’s) for testing and demonstration. Typically tweaks and bug fixes will be needed at this point.

Initial demonstration and testing can sometimes be a point at which the client asks for additional work, beyond the scope of the current project. Seeing work in action can often spur further ideas or reactions. The PM Pavilion member on the project handles these requests, making a call on whether items are within the scope of the current project or should be included in a seperate project.

4 Likes