Great slide shows from Pathfinder
I came across these two great presentations about Agile on the Pathfinder blog, which is something I check from time to time being an Agile development shop in Chicago.
The first slide show is about integrating design in to the Agile process. Something that is not really addressed in the Agile Manifesto, and is something I have posted about before. It is critical area for Agile BA’s to address because the dive in and deliver functional code approach of Agile is great, but can lead to a very haphazard design with no clear vision.
The second one on Writing User Driven Requirements just really helped bring me back again to always thinking about the user. I am certainly prone to thinking about business needs, or developer/technology constraints only, but the user should always stay front and center.
The Business Analyst and Knowledge Management
Knowledge is valuable
I have read a few articles recently that have talked about the promotion potential of Business Analyst’s, particularly at Laura Brandenburg’s excellent http://www.bridging-the-gap.com. What jobs are open to a BA? What skills do you have that can open new avenues? I think this is a very valid discussion as the BA role can seem pretty flat in terms of long-term potential. What is the career path? Senior Business Analyst? Super Senior Business Analyst?
There are typical answers to this, the most common being Project Manager, but that is one that I find distinctly unappealing. I think being an Analyst means you are the type of person who likes to get in to the weeds of a project a little too much for you to transfer nicely to a PM role. In a previous post I spoke about the cross-over between a BA and an Information Architect, and I still believe this is an open avenue, but this may be too “webby” or design focused a step for some people, as well as being a rare field, still growing and maturing and hence difficult to access.
As part of my Masters in Business & Information Technology at DePaul, I am taking a course in Knowledge Management, and it is fascinating. It is such a fuzzy area and almost a non-subject according to some, however I see a lot of value in it. It centers around not only how do we collate what we know in to knowledge bases but also how do we identify, stimulate and capture this information from experts within the organization.
Something that seems very clear to me is how a Business Analyst can significantly help in this area, if they have worked within an organization for a period of time. Over the course of various projects, many interviews have been conducted, problem domains examined and modeled, and a sense of the organizations knowledge centers would have been subconsciously formed. As the BA who is observing and objectively analyzing how information, data and processes flow within a company, they are essentially tracking the knowledge flow through a company, how it is formed and who are the creators, experts, team players etc. who contribute to it’s formation.
So when you are next creating an Activity Model, or interviewing key stakeholders for a new system, keep in mind that you are also tapping in to a key knowledge resource, that has a broader importance. If there is a knowledge management initiative at your company you may then be able to leverage this information outside of the main project focus. But if there isn’t a knowledge management initiative, then maybe this is a good way to propose one and perhaps land yourself with a Knowledge Management project.
Related posts on the Business Analyst career path:
http://www.bridging-the-gap.com/can-i-be-promoted-as-a-business-analyst/
http://www.bridging-the-gap.com/whats-next-what-do-i-do-after-im-done-being-a-business-analyst/
http://www.businessanalyst.com/advance-from-business-analyst-to-business-architect/
.NET developer job
I know this is a long shot but I thought I would post this job that my company has on the off chance that we may find someone, the j0b boards are not providing good candidates at the moment. Leave me a comment if you are interested:
.NET DEVELOPER – Consultancy, Chicago IL – Local Candidates Only
We are a growing, Chicago based consulting company and Microsoft Certified Gold Partner with Microsoft competencies awarded in Custom Development Solutions, Information Worker Solutions, and Data Management Solutions. Local candidates only please, and no corp-to-corp.
Requirements:
• A technical degree in computer science, engineering, or equivalent experience.
• Strong working knowledge of Internet technologies and databases.
• 3+ years of professional programming experience in C#.
• Understanding of the .NET framework, ASP.NET (2.0 and 3.5), ADO.NET, AJAX, and LINQ.
• Test Driven Development experience using Visual Studio, NUnit or equivalent.
• Experience with SQL Server and T-SQL programming.
• Ability to communicate (verbal and written) effectively with a variety of cross-functional groups.
• Time management skills & ability to multitask.
Experience with any of the following technologies is also beneficial:
• Microsoft Patterns and Practices
• Microsoft Enterprise Library
• Microsoft Team Foundation Server
• Microsoft SharePoint Server
• Microsoft Commerce Server
• Microsoft BizTalk Server
• Microsoft SQL Server Reporting
Benefits:
• 401(k) with 4% matching
• Medical and Dental HMO/PPO/HSA
• Flexible scheduling
• Casual environment
Greater compensation considered for exceptional talent.
Please send resume and salary history to the email address above
New job!
On Monday January 18th I will be starting a new job as a Business Analyst / Project Manager, at a small IT consultancy that creates custom web applications as well as offering hosting solutions. They predominantly use Agile methodologies where possible, however the final approval comes from the client, so if the client wants Waterfall then so be it. This is a very exciting move for me, and I cannot wait to get started on Monday.
I started this blog in 2008 to track my career change from a recruiter with 10 years experience to a Business Analyst (hence the blog name, see my first post). My first role however was not ideal, and I knew that going in as it was an Implementation Consultant role for a SaaS product. Although it involved business analysis type work, such as requirements gathering and extensive customer interaction, it was within a very confined environment. Essentially the product existed, we were just tailoring where possible and getting the customer trained, live and bringing in revenue. It was a good starting point but not what I wanted long-term. I entered Business Analysis with the idea of working on new software product development and release, preferably web applications as that seemed so fluid and exciting. This new role seems very much in line with what I saw in my minds-eye when I started this career change adventure.
This new job is a combination, they are bringing together the Business Analyst and Project Manager roles. Previous experience has shown the owners that at present there is not enough work on either side for a full role and that there is also a lot of cross-over. I will get involved in so many different areas, from requirements gathering, developing and managing a project plan, wireframes, information architecture, testing and so much more I’m sure. I have a lot to learn.
I will be working my way through the following books recommended by one of the company owners as I get started, and will post a quick review of each as I go:
- Agile Estimating and Planning by Mike Cohn (1/2 through this now)
- User Stories Applied by Mike Cohn
- Agile & Iterative Development by Craig Larman
- Rapid Development by Steve McConnell
So a new chapter opens in my career change, and again I will be blogging my progress.
I would be very interested to hear from anyone who has worked in a joint BA /PM role such as this, and any other suggestions on readings would be most helpful.
The BA and Expectation Setting
The expectation gap
Expectations can destroy a project. If the stakeholders have inflated, unrealistic expectations, regardless of the projects final deliverable, it will be classified as a failure. The stakeholders will be disappointed and the project team will be demoralized. The BA must play the role of project realist and ground the stakeholders, tethering them to the true idea of what the final deliverable will be. The BA is uniquely positioned to fulfill this “Expectation Enforcer” role because of their requirements gathering responsibilities.
In my current BA role implementing a SaaS product, this is particularly critical. I am the face of the company and product following the successful sales cycle, where they have been courted and wooed with the promises of time and cost savings and a great user experience. During the 2-day requirements gathering meeting which follows the sales to implementation hand-off, one of the big parts of my job is not just gathering functional requirements and building the stakeholder relationship, but also gradually and carefully grounding those expectations which are often floating in the stratosphere.
This is a very tricky, balancing act that requires the BA to use all the soft skills they have at their disposal. The customer’s enthusiasm and eagerness needs to be maintained and nurtured. Kill that now and you set up a long and difficult road for the project. But let them run free and unchecked and you have a bigger problem and will set up the project to fail.
Expectation setting must not mean be negative. The chips and knocks to their ideal of the project must happen organically and naturally as the conversation develops and the requirements are gathered. It is because of this that I feel the BA is perfectly suited to the “Expectation Enforcer”.
With each requirement elicited comes the opportunity to gauge what the customer is expecting.
The BA must address each and every one of these expectations. Probing, questioning, and resetting the scene to approach the problem from a new perspective, just as you would for a functional requirement. As this discussion progresses you must latch on to what to what is possible, and enthusiastically confirm that assertion. As we all know, start with a positive before delivering less favorable news. Then carefully bring the customer down out of the cloud, ensuring they understand the realities of the project. Whether that be the customization limitations of an existing SaaS product, or the constraints of a new development project, where cost, time or scope may mean their expectation cannot be met.
As is so often the case, using visuals greatly assists the process. Working with a SaaS product, I use the requirements meeting to run demos in a test database, and show exactly what it is they are getting at every turn. This works really well at transferring the enthusiasm from the ideal in their head, to how it will actually look and work.
Often the functionality is as they expected, it just works in a different way to the mental model they had developed during the sales cycle.
If working on a new development project, the principles of Agile and User Centered Design will play a big part in reigning in the expectations also. Delivering working products quickly, soliciting constant stakeholder feedback, testing and iterating, will make sure that the customer understands quickly the realities of the project. If you are working on a waterfall project (I feel for you), showing prototypes and using whatever visuals you have to hand as the project develops will help fend off the “this isn’t what we expected” comment when the product is delivered.
I would love to hear other BA’s opinions on this topic, particularly those working on new development projects, and how you approach this critical issue.
Thanks as always for reading.
Case Study Part 2: Process Flow Diagram Analysis
The diagram was a challenge but I will persevere!
Well it took me longer than a week to post the results of my process flow diagram experiment and for that I apologize. I will not bore you with excuses.
A quick recap for those who did not read Part 1 of this Case Study. I submitted a proposal to my boss to add a process walk through conversation with the customer during the project kick-off, 2-day discovery meeting. This meeting is currently driven almost exclusively by a question and answer tool and resulted in a very stale and stunted meeting. My aim was to engage the customer by asking them to tell the story of their current process, which I would capture using a swim lane type model I had developed, for delivery with the Business Requirements Document.
The pilot overall went well, however it was a challenging meeting as the customer was not engaged in the process and had provided little documentation beforehand to help me lead the discussion. But it did achieve some of the goals I had set for the experiment, which were:
- Provide a framework for a free-flowing discussion.
- Elicit requirements that are missed by the basic question & answer format.
- Allow the diagram to be constructed as the discussion took place.
The challenges I experienced were:
- The customer was small and the process being described, although with many parts, was all conducted by one person. Therefore the customer found it difficult to talk through the process in a more abstract way, linking one section to another. This highlighted that I had designed the process with a larger customer in mind and would need to tailor it to a small company setting.
- Creating the diagram neatly, on the fly, was difficult. The meeting was conducted in a restaurant and I had to do the diagram just with a pad and pen. I had not prepared for this correctly, not knowing the setting of the meeting until we arrived, and needed a portable whiteboard, or just plain paper and a pencil would have been better. I will certainly be more prepared next time.
I will persevere with this method however and continue to work on refining it. My boss is still certainly on board with the idea.
Once again it demonstrates the power of iteration, and learning from your experiences. I will do this again at the next meeting and I will now have these lessons learnt and will start from a stronger position. I am striving to make sure I personally review my work and learn from my mistakes. An internal heuristic walk-through of my work output if you will. I must embrace my mistakes and challenging experiences and see them as a valuable part of learning.
Thanks again for reading!
Agile and User Centered Design
Nielsen Norman Group
This new article from Jakob Nielsen was an interesting read. It relates back, in a roundabout way if you really squint at it from a distance, to my previous posts (here and here) on where the Business Analyst fits in to the User Centered Design (UCD) process. Nielsen is looking at the problem from the perspective of how UCD fits in to the Agile development lifecycle. The focus on a rapid sprint style of development leaves little room for user engagement and testing. Furthermore the concentration on small sprints to achieve functionality can be at the expense of a unified, user-focused design and information architecture. Unless of course that UCD is integrated in to the project from the beginning. This is Nielsen’s point.
“it’s important to designate a gatekeeper to track requirements and communications between the UX team and the other project teams to keep everybody on track (even though those tracks are parallel).”
This would be a natural starting point for a BA to again be that bridge between two groups. Although it sounds like a Project Manager type role at first glance, I see greater scope for engagement and influence in the project, and so more of a BA type role. To be the “gatekeeper” between the UCD team and the development team. To integrate the user and design requirements from the UCD side, and working within the information architecture and design principals, bringing that to bear on the functional requirements and delivering that to the development team.
Just a thought.
Case Study Part 1: Adding a process flow diagram to a Q & A driven requirements process
I recently suggested to my boss a way to incorporate a process flow diagram technique in to our requirements gathering process. She liked the idea and allowed me to run a pilot at my last requirements gathering meetings. This is Part one of two articles documenting my experience.
As an Implementation Consultant for a SaaS product, the big kick-off for each project is a 2-day meeting at the customer site. This is a requirements gathering session driven entirely by an online tool that ensures I ask all the critical questions so I can generate the Business Requirements Documents and have the product configured. This question & answer, tool driven process is part of a broader Six Sigma, repeatable and reliable implementation path that the company has invested heavily in over the recent past. This in turn generates lots of data points, measurable and reportable milestones which the QA team use as a stick to beat us lowly Implementation Consultants with when we don’t meet them 
However I felt as though this drive towards fully quantifiable actions and processes had resulted in a very stale and un-engaging requirements meeting. The tool forced the meeting away from a qualitative semi-structured discussion, in to a repetitive question and answer session…for two days!!
- Where was the consultative approach our implementation procedure and job title highlights?
- Where was the business process analysis?
- Where was the free-flowing discussion and use of more traditional BA methods of enquiry and elicitation?
My concerns at this particular issue possibly taps in to a broader problem of operational efficiency programs, such as Six Sigma, throttling fuzzy, qualitative procedures, but that was not my problem to address. However I saw a great opportunity to include a visualization technique to capture the customers existing workflow that would be directly affected by the new software I am implementing. What I proposed was a business process diagram method, but what that would look like I had no idea at the time.
The key objectives were:
- It must be quick and simple to draw / develop in real-time in front of the customer.
- It must generate discussion and allow the customer to walk through the process, as it exists today, with no consideration for how it will change with the new software, or more in-depth technical considerations.
Process Flow Diagram Example
This is the example I developed after some online research (thanks to David Morris @GreySkinnedBoy on Twitter for pointing me to the BPMN) and showed to my boss. It builds on a swim lane type method although it will not conform to the linear timeline aspect normally the case with swim lane diagrams.
My hope is that this high level overview and story telling on the customer’s part will elicit requirements that would normally go undiscovered until later in the process. I also want to create a then and now document so the customer will know how the process will look at the end of the implementation, as well as a proposed process flow diagram if efficiency saving options are open following analysis after the meeting.
Overall I hope the introduction of a visual artifact will offer both value to the customer, improve the requirements gathering process and offer more opportunity for real value add consultative work.
Look out for Part 2 next week to see how the pilot went.
Does the BA look at the user experience?
A paper website prototype
Just a quick follow up to my last post which aimed to gather comments clarifying a couple of points. What are the key functional differences between the BA and Information Architect (IA) roles, and how the split falls between requirements gathering and user centered design (UCD).
I am an avid listener to the Spoolcast podcast from User Interface Enginerring (UIE). It is really informative and Jared Spool always has some great guests discussing UCD and UX topics. One of the recent guests, Todd Zaki Warfel, was talking about prototyping experiences, and during this discussion he touched on the very same role definition issue. Jared at one point posed the question to Todd, does the BA in even look at the user experience? This brought up some interesting points I wanted to share.
Todd felt that the BA’s typical remit on a project was functionality. What functional requirements does the product need to fulfil. So although the BA is involved in the design of prototypes, he saw these as being on the wireframe, boxes and arrows, Visio end of the spectrum. A prototype designed to show that the functional requirements elicited from the users and stakeholders will be met, and visually how those functions will look, in their rawest form.
However an Information Architect or User Interface Designer will approach building the prototype by trying to take it that much closer to the final look and feel of the site will be. Again the functionality will be there, but there would be more care and attention to the usability and user experience with the site. He also felt that the designer would be more willing to take a risk and create something very new, whereas the BA may be more inclined to stick to existing structures. He used the specific example of the designer adding AJAX type aspects to their prototypes.
I certainly think that makes sense and although every BA and IA role will vary from company to company and project to project, I can see this line holding true the majority of times. It does also back up my contention that in fact there is a fine line between the BA role and the UCD process and that the two sides could easily be joined if necessary. This provides excellent room for growth in a BA’s armory if they can bring in valuable usability and user design techniques and perspectives to the requirement’s gathering remit. Particularly when expressing those requirements visually, which always seems to be the best way to really engage the stakeholders in the requirement’s process as they start to see the result to all the questioning.
Business Analyst or Information Architect?
Information Architect or Business Analyst? Which way to go?
This post from Paul Culmsee at Cleverworkarounds.com tapped in to something that has rattled around my head for a while. My career aim is to work as a Business Analyst in software development. I pursued this role whilst still in my old career as I understood that the BA role most closely fulfilled the idea I had of being a bridge between the business and technology. Not that being the business-IT bridge was an original idea, but it was the basis from which my new career direction has sprung. As my knowledge has grown and I have moved in to a semi-BA role (I say semi because half of my role falls under customer service and training), my horizons are expanding and so has my confusion about where the BA fits in to a project and the role they play. It seems the simple answer is that the BA role is however that particular company, or project, defines it. There are common threads of course, the requirements gathering function being the key one, but other tasks and responsibilities float around the position, liable to be cherry picked from organization to organization, project to project. These include PM responsibilities, testing, product strategy and many more. The question I am throwing out to the blogging ether is does it stretch in to the usability and information architecture realm also?
For lack of a better description, this last month I have been gripped, reading and learning about usability, user centered design, user experience and information architecture. As mentioned before, my Interaction Design course at DePaul has really kickstarted this frenzy, but also in working with my friend at Booyant.com, and some possible usability testing and website analytics work I will be doing for them. I think the user focussed and user centered design (UCD) methods are intriguing and certainly something I would like to get involved with. But how do Business Analysts fit in with these methods and roles?
The main reason I ask is that Requirements Gathering is a key part of UCD, as it is for BA’s, so are there BA’s out there who are usability specialist BA’s? Or does the requirements gathering neatly split between user requirements to the usability specialist and the business requirements to the BA? I see how that may be possible with a consumer/public facing product but when the software is for internal use, the user is the business. Who takes the requirements then? It also seems that the usability focused requirements gatherer takes those ideas further down the design path, creating conceptual designs and wireframes to encapsulate the requirements, rather than the BA method of perhaps mapping data flow, artifacts or business processes and documenting the requirements in a traditional style. However use cases and stories are used on both sides……
Lets just say I am a little confused.
Which moves me on to the Information Architect role. The idea of this position seems perfect based on my interests. From the outside looking in, I see the role like the usability focussed BA . It does not fall directly under the creative or graphic design umbrella of software development, so I do not need engage my non-existent artistic side, but looks instead at getting more involved in the layout and structure of the site, mapping the user requirements to software functionality. In that way it seems like a more fulfilling, engaging and strategic position that enables you to put in to action the requirements gathering and understanding work you have done, and structuring the sites information. I particularly like this quote from The Information Architecture Institute(IAI) website:
Jeffrey Veen, Adaptive Path and author, The Art And Science Of Web Design
“I’ve found information architecture serves business as a development process as much as a discipline for structuring content. IA demands a clear understanding of how content can connect customer goals with business objectives. And regardless of medium, that’s the definition of success.”
I love this idea, but as I said I am on the outside looking in, and as Paul Culmsee’s post says, the name of a role can be little more than group of people getting together and forming a club. So is what I described anywhere close to what an Information Architect does?
My research will continue, the Information Architecture book from Louis Rosenfeld and Peter Morville seems like a good place to start and there is a good reading list on the IAI website, but any suggestions and input will be gladly accepted.
Help me if you can.
Thanks for reading.
