Companies love to say they “go the extra mile” for their customers, a phrase that’s beyond cliché. Worse, so many questions go unasked when this is said – how much effort is in the “extra?”   Does a single mile really matter if you have already gone 400 “miles” in a project?  Why does the statement focus on quantity over quality?

At Exsilio Solutions, we don’t focus on the amount of “miles” – we do what is best for our clients. In our experience, the client doesn’t care if you planned and only completed a certain number of “miles;” they care that their project was successful, on time, and exceeded their expectations at every step. 

For example, our project managers are not simply communication pipelines between our tactical teams and the client, managing schedules with just to check a milestone off the list. We expect and train our project managers to go deeper and comprehensively grasp what the requirements are, and completely understand literally every step it takes to get it done. Gathering requirements means not just writing down what you’re told, but listening to the business problem, and shaping the solution to ensure the most success. “Solutions” is a part of our company name for a reason – we’re actively solving challenges, not just building software or marketing campaigns based on what’s heard. In this way, our project managers trend toward hybrid project/program managers by industry definition, but we believe our customers are served better by a partner who can collaborate at any level of detail, with any audience. Project results and client feedback consistently confirm this is a sound approach.

Another example is our creative department. We humbly believe we have one of the best creative teams around. Not only are they skilled graphic artists, but more importantly they put down their digital pens to listen and think critically about business requirements before they create their first pixel. Pencils to paper and markers to whiteboards are how they tackle business challenges first, designing a solution that works to not only meet the customer’s needs, but be accomplishable by the tools available to our developers. With our enterprise application projects, we’re often solving complex user experience interaction challenges. It’s not unusual for our team to discuss a feature at length, create presentation-ready wireframes, and through this process discover a better way of doing it, and then reproduce the entire wireframe to match. The first solution would have worked, and would have technically met the requirements, but it didn’t meet or exceed the spirit of the business problem, so we felt it had to be redone to produce the best result.

This is the pursuit of excellence at Exsilio Solutions. We seek it out and instill it in our team. We apply the principle to our projects with the simple belief that if we do our absolute best for the client, shared success will be self-fulfilling, and the momentum will carry into future projects and a strong working partnership. If you’ve had the chance to work with us before, we hope you agree. If you’re considering Exsilio Solutions for your next project, we look forward to showing you our best.

At Exsilio Solutions, we use the Agile project management methodology for software and solution development projects. Where the traditional Software Development Lifecycle (SDLC) waterfall approach requires extensive design and documentation before a single line of code is written, we find our clients are better served by the Agile approach, which allows for shorter iterations, and changing requirements as development progresses (within reason!). Particularly for our tech clients, business changes fast, and we offer exceptional value responding to those changes with them. In fact, it’s consistently positive feedback we receive from our customers.

But you can only make changes so much, and it does have to be managed to keep from being randomized, as well as knowing when you’re done with a deliverable. Additionally, tweaks to scope usually happen in phone conversations, and sometimes in deep e-mail threads, which are both hard to trace when development is done.

Realizing we need to bridge the gap between being as Agile as possible, and risk having no documentation, we believe strongly in the use of one-pagers. What’s a one-pager? First off, it’s never just one page. But when a new feature set is outlined verbally, or extended from the brief form in the contract, this document is where we expand and detail exactly how the feature will work. Usually they start as a few pages, a narrative into the user behavior when it’s done. We include early mockups, and are careful to call out not only what the feature will do, but also what it will not do. Using the Review features of Word, we can easily collaborate with the client to refine or adjust the one-pager to meet their expectations up front, iterate with it as the project unfolds, and document in one place when those changes took place, and what they were.

By the end of a project, the one-pager typically evolves into a multipage document, more resembling a functional specification, but not quite as detailed as a technical specification.

There are many ways to create these; we find good one-pagers contain the following:

• Title of the project and feature set                                                                                            
• Date the document was created, and last updated
• Changelog of date and what was updated between drafts, in a summary table for quick viewing
• Overview of the feature (one more than one paragraph)
• Background on why we’re building the feature, typically the business problem being addressed
• Details, with a section for each component of the feature. Include mockups or screenshots, if available.
• Appendix with supporting tables, code snipets, etc.

We hope you find them as useful as we do, let us know if you have any examples to share.

Cloud-based offerings in the small-medium business space are finally changing from concepts to real product you can use today. Microsoft launched their Office 365 online suite a few weeks ago to much fanfare, and early indications are a solid competitor in the SMB and even consumer spaces. Even for a first gen product, Office 365 components have surprising compatibility with extending Microsoft desktop applications seamlessly, just like before with more costly in-house hosted solutions.

Sure enough, Project 2010 is in the club, easily integrating with SharePoint Online from the Office 365 suite. One key feature of Project 2010 is the ability to manage tasks on SharePoint team sites, bypassing simple functions done with Project Server in the past, and more importantly showing side-by-side with existing team sites using cleaver templates. If your company is trying to implement team sites and collaboration using Office 365's lower barrier-to-entry hosted model, and you also want to include a project management layer, Project 2010 working seamlessly is helpful for a team with only limited bandwidth and training resources. Also, if you have a team in the field, this makes project plans accessible and interactive from anywhere.

Basecamp has long been an online project and task management offering, but I think this combination of desktop clients, team sites, and task and project management is unique in the computing space, and worth a look alongside Microsoft's Office 365 offering, which requires little to no IT help.

It happens to everyone who uses computers – technology doesn’t always work as expected. Computers crash, files get lost, internet connections drop. As a technology solutions company, software and computers are at the heart of what we do, and how we deliver to our customers. But it’s vital to remember: it’s just a tool.

• Computers do not help us write better.
• Computers do not help us speak to our customers effectively.
• Computers are not required to create project schedules.
• Computers are not a replacement for logical thinking.
• Computers do not help us design as well as paper and pen sketches.

Of course, the first thing that comes to mind is “how can you code software without a computer?” Valid point. Technically, we could write code on paper, but it wouldn’t compile, and certainly would be of no value since it can’t be consumed as a product. But coding is not the first thing we do – a lot of thought and planning needs to go into a project before you code. We try to be as agile as possible, but every project needs a plan, approach, and outline. This is where the computer goes away, and our skills and thought are at work.

If you ask around our office, many of our technical staff prefer to use the whiteboard to anything else. The whiteboard is the perfect balance between lowering barriers between thought and written organization. It also has the benefit of being visible to a small group in the room. Even initial project plans are done easier on the whiteboard, then translated to a tool for easier management and organization. Leaving tools like Visio, Project, and Photoshop behind initially almost always produces better results in the end. It’s how we think about “what” instead of “how”.

When projects get hard or complex, take a step back and focus on core skills with low-tech methods instead of reaching for the computer. You’ll find yourself thinking critically more, and the results will reflect it.

At Exsilio Solutions we use Microsoft’s Team Foundation Server (TFS) 2010 for collaborative development and source control. TFS 2010 also has tools for work item management, offering nice templates for User Stories, Tasks, Bugs, and Test Cases – all elements of the Scrum project methodology we have adopted. Queries on the Team Explorer allow you to view groups of these items easily.

However, one aspect of TFS 2010 needs improvement – Team Queries. The out-of-the-box queries are good for individual developers, but not helpful for the team and project managers. Let’s take a look.

My Bugs, My Tasks, and My Test Cases are good for an individual developer or tester who has items assigned to them, but there’s not a great way to get visibility into all work items at once. That’s because the standard queries have the Assigned To = @Me value.

Also, these queries do not show any closed items. It’s a chore to see what was recently completed by the team, or report on features or bug fixes for past releases.

Product Backlog and Product Planning only deal with the User Stories, the high level containers for Tasks, Bugs, and Test Cases. Unfortunately, these queries only display the User Stories, which require clicking into the individual item, then browsing the links to see related child items. Not very efficient.

In review, the pain points:

• Difficult to see full list of tasks, bugs, and test cases in one place, across multiple resources.
• Hard to see closed tasks, for recently completed items, or reporting on past releases.
• Can’t focus in on a particular kind of work item, at a particular state.

To address these issues, we have created a standard query set we’re using in the Team Queries across a growing number of projects. All of these remove the @Me statement to see across multiple resources, and also target the specific states available for each work item type.

Bugs

We have four queries, three reflecting each individual state for bugs (Active, Resolved, Closed), as well as a query that shows all states together (essentially, All Bugs). 

• All Bugs – Active
• All Bugs – Resolved 
• All Bugs – Closed
• All Bugs – Open, Resolved, Closed

This is exceptionally helpful when preparing status reports, looking through open bugs to confirm they are still open, resolved bugs to see if they have been tested and deployed yet in a build, and closed bugs when the resolution is in a production build.

All Bugs – Active

Change “State=” to Active, Resolved, or Closed to make each query, and Save As… to make your queries for each. Note, if you’re saving to the Team Queries, you’ll need some sort of Admin permissions to write queries there for your team.

All Bugs – Open, Resolved, Closed

For this query, you can simply set these clauses:

Alternatively, you can put each state individually, but you will have to use the OR command on the second and third states, and group the query. This is unnecessary for All Bugs, but in case you need to group two of the three states together, this is how it would look:

Tasks, User Stories

Same principles apply for Tasks and User Stories, just different queries. Change work item type, and cycle through the states.

Tasks

• All Tasks – Active
• All Tasks – Closed
• All Tasks – Active and Closed

User Stories

• All User Stories – Active

• All User Stories – Active and Closed

(I do not use All User Stories – Closed here – we found it had little value. Optional for your needs)

You can also create similar queries for Test Cases. We’ll create these when we migrate our Test Cases to TFS over the next couple months.

Copying Queries Between Projects

Once you have queries set up in one project, copying them is simple. Since all the queries use @Project, they will automatically change references to the project you copied them in. It’s very simple: copy, paste and use, with no additional changes required.

1) Click the first query, then hold Shift and click the last query to select the range.

2) Right click > Copy

3) Right click “Team Queries” in a different project, then Paste.

Simple! You can repeat this every time you set up a new project for standard operation between teams that use different projects. This should streamline expectations for developers, and help with status reporting for project managers.