roberta

You Don’t Need a Methodology. You Need a Toolkit.

0
Filed under Corporate Culture, Growth & Development

Now, before anyone starts typing an angry response, let me say up front that methodologies are fantastic tools. Unfortunately, they are just that, tools. Just like a mechanic cannot fix your car using a single monkey wrench, a Business Analyst cannot effectively perform their job with nothing but methodologies. I have seen an increasing trend in the IT industry that is putting more focus on methodologies. And what’s the problem with this, you ask? They sound great in marketing materials. You can add fancy and colourful graphics that show how a project or task will theoretically proceed. They can be described as “robust”, “comprehensive”, or whatever other buzzword you want to use. In short, they look great on paper and can be very appealing to potential clients. However, as Business Analysts, we are selling ourselves, our chosen profession and our clients short if we rely on nothing other than methodologies.

I encourage you to take stock of what you have in your toolkit. It should contain all of the skills, resources and knowledge that you use to perform your job. This is where the true power of the “toolkit” analogy lies. By putting all of your skills and resources in the context of being a tool, you are forced to identify if you are proficient or weak in the use of that tool. Now, put your toolkit together. Throw your communication, facilitation and documentation abilities in there. Put more specific skills like strategic planning, data design, graphic design in there too, if they’re applicable to you. And yes, put your methodologies in there, they are after all a resource that you use. As you are building your toolkit, keep track of anything that you feel weak at, so you can work on developing those skills.

As Business Analysts, every project or task that we work on will have its own unique attributes and nuances. Those differences may arise due to the nature of the people we are working with, the technologies we’re using, the environment we find ourselves in or the structure of the team we’re on. This is likely not news to anyone, but the key here is that every situation is unique, and it is exactly this uniqueness that makes it impossible to have a “one size fits all” methodology. Go ahead and use a methodology that fits the project you’re working on, but even more importantly, use your skills and knowledge to deliver the outcomes you are responsible for. Remember that the goal of a project is not to successfully complete the steps of a methodology, but rather to deliver value to the stakeholders.

Going forward, let’s refocus on delivering value with the best tools we have. What’s in your toolkit?

robp

SharePoint 2013 Issue Tracking List: Versioning/Comments Dependency

0
Filed under SharePoint

In SharePoint 2013 by default, the Issue Tracking list has versioning enabled and the Comments column has “Append Changes to Existing Text” enabled. These two settings are dependent on each other and the comments fields allows for multiple edits which will each have a unique date/time stamp.

Read More »

robp

Integrate Scanning Software with SharePoint 2013

0
Filed under SharePoint

On a recent project I had a requirement to integrate scanning software with SharePoint to provide an end-to-end solution for getting paper and electronic documents into SharePoint with meaningful metadata applied. The metadata columns in SharePoint included Managed Metadata columns for document categorization and business units, as well as an External Data column connected to a SQL Server database.

The issues I needed to solve were:

  • How to have metadata enforcement using mandatory fields while making the user experience quick and easy.
  • The scanner software did not provide a good user experience for setting Managed Metadata columns or External Data columns so these columns needed to be set in the SharePoint form. I needed these columns to be mandatory so if they were not filled in by the scanner software then the documents would remained checked out and only visible to the owner of the document.

Read More »

robp

Visual Studio – TFS Settings

0
Filed under .NET

We use Visual Studio and Team Foundation Server (TFS) as the primary development tools at Quercus. I find these two tools to be excellent, but there are few integration settings between the two of them that are not the default (even though it seems logical to me that they should be the default).

Read More »

robp

SharePoint Search Display Templates – No Line Breaks in ManagedPropertyMapping List

0
Filed under SharePoint

While creating a SharePoint Search Result display template to display a user’s profile information I needed to configure a large list of managed property values inside the ManagedPropertyMapping tags. The list became very large so I thought I would add some line breaks to group the properties into the same groupings that they are displayed in the HTML.

Read More »

emily

The DOs and DON’Ts of Working with a Designer

0
Filed under Corporate Culture, Popular, Usability

DOs+DONTs

  1. DO: Communicate
    DON’T: Expect a mind reader
    Communication is an integral component to any project, be it design related or otherwise. No communication or miscommunication can tank an entire project. From the first meeting with the designer, work together to create a clear project vision. One of the most helpful pieces of information you can provide during this meeting is a selection of examples of other similar works that you like. Collaboration with the designer during the entire project is also necessary. Establish a communication schedule so that the project remains on track. Ensure that this schedule is adhered to. If a designer doesn’t hear anything throughout the project they assume that everything is going well. No designer is going to be happy if presented with a laundry list of changes at the end of a project.
    Read More »
paulg

Lessons Learned about Project Management Officers

0
Filed under Corporate Culture, Developing Teams

If you’ve ever been in a management or leadership role on a project  (and yes, there is a distinction between management and leadership), I’m sure this list will resonate with you. This is a compilation of published Lessons Learned by Derry Simmel, a North Carolina project manager.

These are the 10 most common Lessons Learned by enterprise project teams, as reported and published by their PM Offices.

1. The people we had were great; there just weren’t enough of them.
2. We left management and planning unattended for too long.
3. Unclear roles and responsibilities led to confusion and loss of precious time.
4. We had the most success when we were all informed.

Read More »

paulg

‘Busy’ Is Not a Badge of Honour.

0
Filed under Corporate Culture, Developing Teams, Growth & Development

When people ask you how work is, do you reflexively respond ‘work is busy’?  While you likely have many outstanding tasks on your plate and projects that need your diligent attention, ask yourself these two questions:

1) Is ‘being busy’ part of your self identity?

2) Does ‘being busy’ mean that you are also productive?

Paul Andrew, a blogger with theLeadershipCoach.com, suggests that if being busy = part of your self concept, then something is amiss.

Read More »

Copyright 2014 by Quercus Solutions