In our environment, in order to maintain quality of the project and make sure communication is flowing to the right people, the BA needs to step forward and own the PM space. Doing the requirements piece is essential and is a first step; the information then needs to flow downstream to all the other parties in IT. The BA is at the forefront of this endeavor. If the BA stops there and expects the PM to take care of the flow of communication, the project more than likely will come to a grinding halt; either that or it will start to flounder. The BA should either work hand-in-hand with a PM who does take ownership and is vitally interested in delivery of the project OR the BA should own this piece as well and ensure that the right people are playing their parts & on time; thus the BA is acting as PM.
The benefit of having a BA act as PM on his/her own project is that since the BA is present at the inception of the project, s/he has interacted with end-users and felt their pain, needs, requirements, etc. from a first hand basis. This makes the BA a representative of the business and the BA can really strive for what is important. The BA playing a PM role can stress the right areas to focus on in the short-term and push off the less important items. A separate, detached PM may not take these things into account, especially if s/he is not as invested in the project. In fact, having a PM involved at the outset may be too much overhead.
The beginning of the project is very vital. A BA/PM can push for a working first iteration of the software that does the most important things first; the initial software will have limited functionality and the BA/PM can even act as an initial QA resource, vetting the design and construction of the software as it progresses by doing quick checks of functionality; and in order to make sure the software is aligned with the original vision. The BA in fact is in a most unique position, especially at the beginning of a software project, because s/he can play those 3 roles: BA/PM/QA and the reason should be blazingly clear; The BA is the one who feels the client's pain and will do his/her damnedest to make sure that the client is being given what they need (if you're a conscientious BA that is)
As the project progresses, matures and gets more intricate, there will have been some momentum built and other dedicated resources can be brought in to handle specific areas of the project: a dedicated PM, junior BAs, dedicated QA, etc.
Friday, March 28, 2008
Get Developers thinking in terms of Features EARLY
Developers aren't used to thinking in features at the beginning of projects. They are usually so engrossed in the details that they immediately start thinking of the tasks they need to do in order to build a piece of software.
Show them a mockup of a screen, give them sample data and whatever else they need, and developers will immediately list their tasks:
1) Create database schema
2) Normalize schema
3) Create middleware
4) Create screen
etc.
The problem is that users and BAs (and everyone else who rolls onto a project after it's started) talk in terms of features. There is a fundamental communication problem.
So how do you effect this transition of language that developers speak from tasks -> features?
As a BA, specify to the developers that you want a first round iteration of software that does the bare-bones. Pick the 2 or 3 important pieces of functionality; intentionally limit the scope and let 'er rip! If developers come back with something they feel is too complicated or unknown, defer it. The BA should be able to specify EVERYTHING in the first iteration. There should be no loose ends. This allows the developers to go away and code; if they have questions, the BA can answer them and if need be, further limit the scope.
Now, let's say the developers have done their part and delivered a working piece of software for the first iteration. If the BA gets a few people (including people who may not even be on the project) to put their eyes on the software along with the developers who created the software, those people will give a tremendous amount of feedback.
But these people (who may or may not be developers themselves) will naturally start talking about what the software lacks or needs more of or could be better, etc. They'll be speaking in terms of FEATURES! The developers who hear this then start to think in terms of features.
The cool thing about having a working piece of software is that once it works, there is tremendous incentive to keep it working! If developers implement something that breaks the software, they'll back up and fix it! Once you have running software, you're not thinking in terms of tasks to get the software up and running. Now you're thinking of what new features you can add! This allows IT to organically grow the software to fit user needs; and not to create something big, ugly & over-complicated that was never needed in the first place. This can easily happen when you're in 'design' mode and thinking in terms of tasks.
Once the developers start thinking in terms of features, then they'll think about the tasks they need to get it done on their own. But now the channel has been crossed; BAs, PMs and Developers can start talking in the same language: in terms of features. The sooner this transition happens the better. What's required is getting that first working iteration out the door.
As well, talking via 'features' makes everyone naturally more delivery-focused. Features add value and customers are able to naturally relate to that; they'll instantly understand what you're talking about.
Show them a mockup of a screen, give them sample data and whatever else they need, and developers will immediately list their tasks:
1) Create database schema
2) Normalize schema
3) Create middleware
4) Create screen
etc.
The problem is that users and BAs (and everyone else who rolls onto a project after it's started) talk in terms of features. There is a fundamental communication problem.
So how do you effect this transition of language that developers speak from tasks -> features?
As a BA, specify to the developers that you want a first round iteration of software that does the bare-bones. Pick the 2 or 3 important pieces of functionality; intentionally limit the scope and let 'er rip! If developers come back with something they feel is too complicated or unknown, defer it. The BA should be able to specify EVERYTHING in the first iteration. There should be no loose ends. This allows the developers to go away and code; if they have questions, the BA can answer them and if need be, further limit the scope.
Now, let's say the developers have done their part and delivered a working piece of software for the first iteration. If the BA gets a few people (including people who may not even be on the project) to put their eyes on the software along with the developers who created the software, those people will give a tremendous amount of feedback.
But these people (who may or may not be developers themselves) will naturally start talking about what the software lacks or needs more of or could be better, etc. They'll be speaking in terms of FEATURES! The developers who hear this then start to think in terms of features.
The cool thing about having a working piece of software is that once it works, there is tremendous incentive to keep it working! If developers implement something that breaks the software, they'll back up and fix it! Once you have running software, you're not thinking in terms of tasks to get the software up and running. Now you're thinking of what new features you can add! This allows IT to organically grow the software to fit user needs; and not to create something big, ugly & over-complicated that was never needed in the first place. This can easily happen when you're in 'design' mode and thinking in terms of tasks.
Once the developers start thinking in terms of features, then they'll think about the tasks they need to get it done on their own. But now the channel has been crossed; BAs, PMs and Developers can start talking in the same language: in terms of features. The sooner this transition happens the better. What's required is getting that first working iteration out the door.
As well, talking via 'features' makes everyone naturally more delivery-focused. Features add value and customers are able to naturally relate to that; they'll instantly understand what you're talking about.
Thursday, March 20, 2008
IT is the problem!
What has slowly revealed itself over the last few weeks is pretty insane! But I had a glimmer of insight a little while ago which gnawed at me and I'm fairly certain that this is the central issue: that IT is the source of our own woes.
Much as we would like to (and actually do!) blame our customers and clients, IT is the guilty party. Certain refrains can be constantly heard:
"They don't know what they want!"
"Why can't they make up their minds?"
"They're asking for the impossible!"
and on and on.
Frankly, in my experience, when talking to the business, I can pretty much be open/honest about what can/can't be done & how long it's going to take. I mean these guys don't know IT and a lot of them don't pretend to. They really have to go by what you say. So unless you're just plain intimidated by the business (and a lot of IT ppl ARE) in which case you'll overpromise stuff, the business will take you at your word and get on with their lives. After all, they have more important things to do like make $$. It's our fear or overeagerness to please that gets us in trouble here.
But even more than that, recent experience has shown me that I as a BA am actually afraid of my development team! I've been nervous changing requirements on them because I fear they'll get angry or lash out and give me those above retorts (in other words, treat me as if I'm the business, although I actually AM playing that role; but the difference is they'll say it to my face). Sure, I can pass the buck to the business, but as the BA, I am smart enough to know how requirements gathering works. It's done iteratively; no customer knows what they want right off the bat. Everything in the beginning is an approximation. However, dev teams think it's written in stone and proceed that way. Then when the BA comes back with more detailed/refined info or changes the plan, the grumbling begins.
What's needed is for IT to be patient; to realize that they shouldn't put much work in the beginning of a project in terms of development, and that things can change. If the initial plans are vague, then build a fuzzy prototype that does the bare minimum. but above all, EXPECT CHANGE. Because if you expect it, then you're prepared for it. If you're prepared for it, then well, there's nothing to complain about when it actually happens. I am working with an off-site dev team now and I said from the get-go that the project is going to be iterative and that we'll need to do several versions. Well, whaddaya know? We got some more stakeholders involved and they requested their own changes. So back to the drawing board! But this is great, because everyone's voice is heard & we have more information as a result of the 1st iteration as well.
Much as we would like to (and actually do!) blame our customers and clients, IT is the guilty party. Certain refrains can be constantly heard:
"They don't know what they want!"
"Why can't they make up their minds?"
"They're asking for the impossible!"
and on and on.
Frankly, in my experience, when talking to the business, I can pretty much be open/honest about what can/can't be done & how long it's going to take. I mean these guys don't know IT and a lot of them don't pretend to. They really have to go by what you say. So unless you're just plain intimidated by the business (and a lot of IT ppl ARE) in which case you'll overpromise stuff, the business will take you at your word and get on with their lives. After all, they have more important things to do like make $$. It's our fear or overeagerness to please that gets us in trouble here.
But even more than that, recent experience has shown me that I as a BA am actually afraid of my development team! I've been nervous changing requirements on them because I fear they'll get angry or lash out and give me those above retorts (in other words, treat me as if I'm the business, although I actually AM playing that role; but the difference is they'll say it to my face). Sure, I can pass the buck to the business, but as the BA, I am smart enough to know how requirements gathering works. It's done iteratively; no customer knows what they want right off the bat. Everything in the beginning is an approximation. However, dev teams think it's written in stone and proceed that way. Then when the BA comes back with more detailed/refined info or changes the plan, the grumbling begins.
What's needed is for IT to be patient; to realize that they shouldn't put much work in the beginning of a project in terms of development, and that things can change. If the initial plans are vague, then build a fuzzy prototype that does the bare minimum. but above all, EXPECT CHANGE. Because if you expect it, then you're prepared for it. If you're prepared for it, then well, there's nothing to complain about when it actually happens. I am working with an off-site dev team now and I said from the get-go that the project is going to be iterative and that we'll need to do several versions. Well, whaddaya know? We got some more stakeholders involved and they requested their own changes. So back to the drawing board! But this is great, because everyone's voice is heard & we have more information as a result of the 1st iteration as well.
Saturday, March 15, 2008
BA Skillset
Here are some skillsets and basic tools that I feel a BA should have:
Learning Access is one of those things that can put you over the top. You can quickly create solutions for small groups of people and do a bang-up job. There're lots of instances where a simple Access database can do the trick but many BAs don't have the skillset to address them. Instead the project become overblown and a 3 tier solution with an Oracle DB and a middle tier and a web front-end are devised. This takes too long, is too expensive and more likely than not, you'll have to wait for resources to be freed up.
Training your users to use an Access Database is also probably a good thing to do. Lots of spreadsheet users invariably complicate their spreadsheets with tons of tables and VLookups, whereas a simple join in Access would do the trick.
Another useful thing with Access is if you do lots of data analysis. Comparing reams of data and figures on multiple Excel spreadsheets can get quite laborious and tedious. If you dump each of the sheets into their own tables in Access and do joins you can quickly find which ones match and which ones don't for example. Access (or knowledge of some database) is a must for the serious BA.
Other skills:
A balance b/w taking into account the customer's concerns vs. ability to drive a solution forward is quite key: Let's face it. If you were to build a solution that took into account EVERYTHING, you would be in a quagmire. Automating error handling for every instance of something going wrong can be fruitless. Some things should just be manually handled. A lot of people, both BAs and customers get caught up in thought exercises and intellectual games following all kinds of paths to come up with some grand solution. Implementing something like this and then debugging it can be a nightmare. Remember that you need to not just satisfy your clients but your dev & qa teams should be considered as well. If your solution solves 80% of the customer's problems, then you should strongly consider pushing that forward. The rest can be 'phase 2-ed'. When I use this phrase, it allows the customer to relax knowing we can deliver something quick in phase 1 that'll handle most cases and then we'll handle the rest later. But you know what? Many times Phase 2 never even happens because Phase 1 is completely adequate!
- MS Office Suite
- Word
- Powerpoint
- Excel
- Access
Learning Access is one of those things that can put you over the top. You can quickly create solutions for small groups of people and do a bang-up job. There're lots of instances where a simple Access database can do the trick but many BAs don't have the skillset to address them. Instead the project become overblown and a 3 tier solution with an Oracle DB and a middle tier and a web front-end are devised. This takes too long, is too expensive and more likely than not, you'll have to wait for resources to be freed up.
Training your users to use an Access Database is also probably a good thing to do. Lots of spreadsheet users invariably complicate their spreadsheets with tons of tables and VLookups, whereas a simple join in Access would do the trick.
Another useful thing with Access is if you do lots of data analysis. Comparing reams of data and figures on multiple Excel spreadsheets can get quite laborious and tedious. If you dump each of the sheets into their own tables in Access and do joins you can quickly find which ones match and which ones don't for example. Access (or knowledge of some database) is a must for the serious BA.
Other skills:
- SQL
- Communication/Writing Skills
- A strong desire to play with & learn new software; being a software evangelist
- An ability to filter out extraneous information and to focus on the details that drive a project forward rather than getting bogged down with too much detail: There's a time & place for everything. Sometimes getting all the information up-front is not such a good thing (your head probably won't be able to process it :)
- An inquisitive nature to find out what people do & why they do it. As a BA, you need to help automate things for your customer so you need to drill into all the particular details of what they do, what actions to take when certain events occur, when they do it, how they do it, how they know when to do it, etc. Getting the whole picture will eventually reveal the grand scheme and then you will be able to propose a solution.
Subscribe to:
Posts (Atom)