Success for the PM/BA's

I’m really, really happy right now since our first Business Analysis Requirements Gathering project was a success. We were finally able to have our deliverables approved and signed by the client. The sign-off document also states that “…the documents [we did] capture the requirements defined in line with the agreed scope of the project… the deliverable submitted has been delivered with quality and on time as per the schedule defined”. It’s the first time for the project management department to handle such project and we’re proud that it worked out well and delivered on time and with quality. We all hope that we can add more endeavors for the Project Managers / Business Analysts in order to support the objectives and goals for the company for 2008.

Thanks to all the PM/BAs, especially to my teammates in the project, Jo and Richard!

Preparing for the Battlefield

For about two months now, the O&B Project Management team has been consistently meeting to re-evaluate and improve the PM practices and tools in a systems development project. Our hard work has been paying off since we can evidently see our progress through the project management topics that we’ve discussed and finalized such as setting a standard processes for the project proposal and preparation stage, a checklist for project preparation, a standard communication plan, change request process and a risk assessment plan, covering the different risks that usually occur during a systems development project along with an action plan on how to handle the risk.

As new projects are coming in, our goal is to equip and train the PM/BAs with the necessary requirements needed for systems development projects. To reduce the risks and the learning curve involved in one of the new projects, the PM team (less Clair) decided to attend a free seminar on stocks to learn the terms and rules involved in the new business domain our project will cover. I was really excited to attend this seminar since I personally wanted to learn more about stocks and I didn’t have any idea on how the stock market runs. Personally, I think that the seminar we attended was really informative since it gave us a picture of how stocks are bought and sold, how the stock market runs and what some investment terms mean, some of which we’ve never even heard before. Come to think of it, this activity will not only help us PM/BAs do our work but also give us knowledge on the different business domains that we’ll have to study and handle for projects such as payroll and stocks. It’s certainly one advantage that we BA’s have since we personally get to know more about other business domains as well.

I think we PM/BAs should have more of these seminars on business domains (especially before a sure project) since it will assist us in doing business analysis especially if the PM/BA’s don’t have any idea on the business domain. In this way, we PM/BA’s can reduce asking questions like what a certain term means and get straight to the point and focus on actual requirements gathering and analysis. Through this activity, we can be more prepared to handle the business rules and requirements of the project and as well as reduce the learning curve upon execution of the project.

The remaining and most challenging part, I guess, is just for us to actually use everything we learned from the seminar and pm trainings, and see how far we’ve gone in preparing ourselves for the systems development project to come.

Some Thoughts and Plans on Documentation

I’ve been thinking for a few days now on how we can properly document all the data needed in a project. Currently, I’m trying to list down the documents needed and comparing it with what we learned in the ISAC training last April. Although we’ve created a list of documents last December, I don’t think that it’s enough - meaning the data captured by the documents we listed does not reflect all that is needed in a project (looking at it now). I’m also thinking on how we can fix the format in order to have the data in an organized manner, capture even at least 60-70% of the data needed upon creation (since I learned that it is impossible to understand everything at once, there will always be room for questioning and business analysis is not just captured in one stage) and, of course, not eat up too much time in creating the document since it will be needed for sign-offs and for communicating the business rules to the team.

Right now, I’m already done with some documents in my current project. The project’s going to end soon, hopefully, and I’m going to be focusing on completing my documents again, since I put it on hold in order to focus on coordinating the business rules with the team, assigning tasks compared to the schedule and testing. Although some documents are already done, I’m still going to “try” to revise the format of some documents in order to see if the new documents/format will capture the data required. I think it’s best also to try new formats/documents at this stage since I’m quite confident that around 90-95% of the business rules have been captured (thus, we’ll be able to check if the documents properly capture almost all the requirements). And thanks to version control, if I don’t finish on time, I can always revert back to the previous state. If I finish on time then I’ll be able to use my proposed format for this project.

After the project, maybe we BAs can criticize, analyze and improve the documentation process and create some standard procedure (or something) that can also help us improve our tasks or responsibilities in a project.

Note: “try” – since I’m not sure if I can add this to my current tasks during office hours… maybe I'll have to fix the documents after office hours… still have to see…

Fire Alarm Experience in ABS-CBN (February 18, 2007, Sunday)

Owie, Glenn, JP and I decided to go to ABS-CBN to continue our work in the office. Owie and I decided to come early in the afternoon while JP and Glenn decided to come after dinner. While Owie and I were facing our laptops working around 3pm, the fire alarm started to go on. We both stood up and looked outside the cubicle since the people who were here started moving. We were just standing outside the cubicle watching them when I said, "Ano tara?". Then, I thought of our laptops and said, "Wait, ididisconnect ba natin laptops natin" which was followed by "Jacket ko" and later thinking about bringing OB2 and the server. We looked outside the window for signs if there was really a fire here in ABS-CBN (smoke or people looking at the building) or if it was just a fire drill. Anyway, Owie just said: "Wala namang tumitingin sa building e". So we didn't move anymore and stayed.

It was really funny because even though there was a fire alarm, we were moving so slowly and relaxed even though we were a bit curious what was happening and even if there was really a fire...

6 Months Worth

After almost 6 months, my first two “out of school–real life” projects are finally coming to an end. Truly, it has been one unforgettable experience since so many things have happened in just 6 months. I remember joining the company late August after thinking for about a week or so if I should accept the offer given to me. So many things came into my mind then. What if some multinational company would offer me a few days or weeks after? What if the negative prediction that the fortune teller mentioned would come true? I talked to Ealden about it and asked for more information about the company. I asked about training. There was none. According to him, experience is training itself. I asked what if I screw up. Well, he said that we’re bound to make mistakes but what’s important is that we learn from it. After conferring with a lot of people and seriously thinking about what I want in a job, I finally accepted the job as Business Analyst and Project Manager and was immediately assigned to my first two projects.

September

During my first month into the project, I was really, really nervous. I didn’t know what to do exactly since it was my first “official” work and the methods used in the company were different from the things I learned in school. In Ateneo, we learned what they call the “Waterfall Method”. But in Orange & Bronze, they were using the “Agile method”. I only learned the Agile Method by reading about it in the websites / e-books provided to me and through the discussions I had with our team lead, JP. Other than that, I had zero knowledge about it. I had faith that I’ll probably learn it as we progress in the project. Then came documentation. As Business Analyst, it’s our duty to understand the business (how it is currently running, what the client expects from the new system) and how we can interpret it in the way that our developers would easily grasp these requirements. With the first project, the client gave a long detailed document about it so I thought that this could be enough. Maybe all I have to do is summarize it and give a list of System Requirements based on the document. For one, I didn’t know what documents to write or what documents were needed so I just started with that. After some time, questions kept coming in and I finally realized that what I did was not enough. I had to gather data further and find a way to really document the details.

October-Mid November

Around the second month and third month, I was assigned to start collecting data for the second project. After reviewing the PowerPoint Slides, which was the only initial document they had about the second project and only contained 22 pages (four slides each page), I began asking questions. One question led to another question and another question. Looking at the data needed, I, along with Clair (my BA/PM partner), started to formulate a document that would reflect the business requirements, data needed, etc. We initially called this the “Business Rules and Requirements”. As the project progressed, we started making revisions until it became better. We found some elements that were lacking and added to the document. In the end, this document became a combination of the system requirements, data requirements, semi-use case, database tables and columns, etc. (Yup, it was a pretty long document!). Why this long of a document? Well, we had to prepare for the developers coming in from the first project so we thought that we didn’t have time to create other documents so we decided to stick with one document first, while one person does one part, the other does another part. Another reason is that we didn’t have a standard way of documenting or simply, the documents needed in a project and what the document contains.

Mid-November-December

Around mid-third month to the fourth month, my PM side really hit me. Focusing too much as a BA in the previous months and after finally understanding what is expected from a BA, I honestly can say that I slipped away from some of my PM tasks. I did assign tasks, schedule meetings, monitor people’s whereabouts but one element that I forgot to look into was the schedule and it really hit me hard. Then I realized that I wasn’t juggling my tasks effectively. I finally realized that extensions in meetings or any issue or blocker should not hold you from progressing. I started learning how to manage Wiki / Trac – setting up pages, understanding the format, etc. I also began to help in monitoring the progress of the project and the deadlines we had to reach. Finally, during the Christmas week, we formulated a list of documents needed in a project and the details along with it to help the BA’s in the next projects to come.

January

On the fifth month, I can say that I started to learn how to juggle both my PM and BA tasks. With my BA work came coordinating with the developers, handling tests, monitoring the changes in the business rules, documentation, etc, while my PM side has to monitor the progress/schedule, handling and assigning tickets, schedule meetings (both O&B and ABS), monitoring people, etc, etc. It’s not an easy task. I still have some flaws. I still have to learn more and improve managing both myself and the projects. Although it may be difficult at times, I have no regrets. This is the path I chose and this is really what I wanted as an MIS graduate. Besides, beyond the stress and the pressure, I’ve met good friends along the way, I’ve learned a lot as a Business Analyst and Project Manager in a real-life project and, I learned that truly, experience and making mistakes is part of the training or the learning process itself.