The Business Analyst / Project Manager Combo

Until I started looking for work as a Project Manager years ago, I did not know what a Business Analyst was. I knew the title existed, but I couldnt have explained to you what they actually did. I existed in happy ignorance regarding this subject for some time. Through the years, I found out that there actually was something called a Business Analyst, and that they did what I did as a Project Manager, only on a finer scale and better than I did it.

This is of course, erroneous. There is a lot of confusion out there as to what a Project Manager does as opposed to a Business Analyst – and if not confusion, overlap. While at larger companies and more well-defined organizations you might have a BA and a PM who are not the same person, many smaller companies and companies with less IT staffing infrastructure call this person the Project Manager and nobody knows that they are not, strictly, a PM. Well, I guess they are a PM, just a multifunctional PM. Anyhow, typical tasks that you will see on the plate of a PM (that are really BA tasks) may include:

1. Requirements Documentation, particularly Business Cases and Functional Requirements Documentation is really a task for a Business Analyst. In your smaller companies, you still have projects with requirements, but the projects themselves are less likely to call for a full-time BA. So, the PM winds up doing the work. I never minded. In fact, knowing how to use UML is a great way to impress people really quickly and establish that you know what you are doing (even if you don’t). UML is a fantastic language to know anyhow. I find myself making Sequence Diagrams of my wedding ceremony. Really. I am that ridiculous.

2. Managing the Traceability Matrix. It makes sense that a PM who is watching a project from Inception to Deployment would make sure that the Requirements are monitored closely, but the Business Analyst who originally defined the Requirements is the one who should ideally be following a line of continuity from Requirements to Testing. If a small company is lucky enough to have a PM who has created a Traceability Matrix and keeps it up to date, they are lucky as can be and need to make sure that their employee is getting rest, because they are taking on a lot of work by choice. I always had a Traceability Matrix because I was scared to death that my projects would fail. It seemed a great way to make sure that at the very least, what the stakeholders signed off on is what they got. Early in my career, 8 or so years ago when I first used Traceability Matrices, a thorough Traceability Matrix was my peronsal measure of success. Now, that measure has changed. It does, however, mean that the project was managed from Requirements to Deployment.

3. Business Use Cases. A lot of you are giving me a “duh” right now, but believe me; there are a lot of organizations that rely on their Project Managers to draw up their Business Use Cases. Who else is going to do it?

I am thankful that I was not clear as to the delineation between a BA and a PM until a few years into my career. I learned a heck of a lot that can be useful and coming from a Development background, the BA tasks actually made transitioning to Project Management much more sensible.

If I am a PM looking at a bunch of WBS entities, I can assign resources, budget, figure out the Critical Path, and do all kinds of management-based activities. If I have BA knowledge behind my PM knowledge, I might know how likely it is that a specific item will actually take 21 hours to do and that really, it could be combined with another item to yield a piece of functionality that is more effective, extensible, and robust than the two functions alone. Sometimes it is easier to build something generic and deploy it in instances than to build disparate, specialized objects.

The .NET library, Joomla! CMS, and other development/deployment tools give Developers a ton of really cool functionality that is almost as simple as drag and drop. A PM with BA background, working in information technology, can become educated in the functionality within development tools and proactively leverage them towards the Solution they want to build. I am not sure this is the best thing to do, always, but it can be done and is certainly helpful to a small organization with a small IT staff and limited timeline or budget. Really, any side of the Triple Constraint triangle can be shortened by a good BA/PM with some technical knowledge. It isnt always immediately apparent, however, where the solution is forcing an interpretation of the issue at hand.

Very recently, I began work on a SharePoint 2007 (MOSS) project. MOSS was being customized for the project before the Requirements were done. The PM in me did not like that at all, but the BA in me found real value in picking a tool and utilizing the OOTB features that it offers. While I do not believe that Design can *ever* come before Discovery, a good BA/PM can be aware of what the Business Needs are and visualize a roadmap towards delivery that is based upon the software package’s native abilities and makes the project itself easier to estimate in terms of time and cost.

There is overlap, and I am aware that there is a difference between a Business Analyst and a Project Manager, but I believe that the delineation should only exist where it is of obvious benefit. Otherwise, you have more communication overhead and a host of other issues that come into play with team management.

I am glad I learned the hard way. If you are a PM doing BA things, you’re lucky… and valuable.

And tired, I bet.

Best,

Josh Milane

MIT Technical, Boston

A Paradigm Shift in Semantic Web Deployment?

I am a big proponent of all things Semantic. I have a degree in Philosophy, and the Philosophy of Language was what held my interest over the years. Even the idea of Ontologies is something that I have somewhat of an emotional connection to; the relationship and existence of things within the world is partly a semantic question, partly an issue of theism, and partly a great big sticky ball of epistemological wax. The Semantic Web is obviously something that I support, not only because of how it would advance productivity, expand human knowledge, and connect Systems. The main reason I dig it so much is that it could create something truly Good out of the WWW. It would help us make sense of all the data out there, stored in disparate Systems, strewn about intranets, extranets, and the Internet.

I don’t think there are many who would disagree that the Semantic Web *could* and maybe *would* change the world (or at least the way we operate within it, since the world is by it’s very nature ever-changing, right?). There are those who are cautiously optimistic and have laid down the framework that would be required if the Semantic Web is to become a reality. There are those who are ambivalent about data altogether, so long as Dancing With the Stars isn’t affected. There are also those entities, such as Google, who don’t outwardly support a Semantic Web, yet could have a massive effect in it’s becoming a reality and are benefiting from some version of an applied semantic web. Google is not against the Semantic Web, in that they do not do anything to prevent it’s emergence, but as the Semantic Web would involve quite a paradigm shift, Google is not waving the flag as high as it could. Google has displayed a more pragmatic pessimism, while making a nice living with contextual ads. There are different flavors of semantics. The Semantic Web (with all caps) is a vision of Tim Berners-Lee, and it certainly could be a reality. Google has stated that people are too “incompetent” for it to become a reality, but I think that is a purposely misleading statement on their behalf.

While I do not agree that it is “incompetence” that prevents the average Webmaster from implementing RDF and other Semantic tools, I do think that the web is going to change due to what makes life easier for Webmasters, business owners, and other stakeholders *now*. SilverLight is Microsoft’s new browser plugin, and it was suggested to me earlier this week that instead of web Developers writing HTML to please browsers and to render in FF or IE, they will be writing applications to deploy within plugins such as SilverLight. This is important. If the model changes so that Developers write for applications, there are many implications upon data and upon the WWW – web services and Semantic Web Services included.

It makes sense. Take a look at all the functionality embedded within Visual Studio and try to argue that OOTB tools such as they are have less intrinsic value to the average business owner (with the average IT staff) than the Semantic Web. One has M$ behind it, along with all the immediate value it carries. The other has promises of collaboration and a future where machine agents do intelligent work for us.

I will be frank, although I am sure that what I have to say isn’t going to be that popular: “Web 2.0″ is not all that interesting to businesses outside of advertising. Blogs are online diaries. Social Networking is people talking to people. Yes, these are severe and maybe unfair generalizations, but let’s face it; the people who are using Social Networking the most are not using it for purposes of facilitating business. Sites like Facebook and MySpace are immensely popular, but the folks who make money here are the advertisers and the sites themselves. The sites are akin to toys with massive billboards on the sides of them. This hasn’t been a movement towards a more valuable web, because there is no recognized authority, no Standardized Ontology, no substantive connection throughout. Work flows exist independent of Standards, and communication happens in proprietary space.

Even Second Life with it’s Linden Dollars is dependant upon Visa, MasterCard, or some real entity with standards, insurance, true grounding and defined components to support it.

Web 2.0 has not done a heck of a lot for business, itself. Google itself enjoyed “viral” popularity. Developers were using it before anyone. Kids were using Social Networking before LinkedIn was popular. Businesspeople are generally too busy to be futzing around with the “cool stuff” online. They spend their time with the “productive stuff” and now find that some of the cool stuff can be productive, if you planned ahead and positioned yourself correctly. Google plays very well towards the convenience factor. Have you seen Google Street View yet? It is COOL. Will it make the world a better place? I doubt it. Will it make Google more popular? You can bet on it.

Meanwhile, business is being done on the web. Content Management Systems and Portals such as Joomla and Sharepoint will enable business. They have tremendous value to the business owner. They allow for Social Networking, collaboration, information sharing, but also have ecommerce capabilities (.NETcart and others) and help folks make money. They contain work flow management tools, to help folks run their businesses. They don’t have an immediate “wow” factor like Google Street View, but I sure think they are cool.

Microsoft is Google’s obvious competitor for mastery of the Globe’s data. The Sharepoint Server 2007 platform is Microsoft’s newest offering. It is amazing. It can do amazing things. However, because it is so dynamic and renders so much on the fly MOSS is not totally Standards-compliant. This is a big deal. This says, “our tool is so good that Standards will just have to forgive us…”

Standards must be preserved, however. And Microsoft would be wise to obviate a way to implement RDF or Semantic technologies.

Web Developers and Architects have a variety of landscapes that they can paint. They can paint an Open Source landscape, where the edges are a little fuzzy but the population is enthusiastic and there are no secrets. They can paint a Microsoft or other proprietary landscape where things are very well defined, but expensive. They can act based on what they know in either one of these cases, drawing on .NET or PHP experience and deploy. They can deploy something that works for business, or something that works for Business. Either way, they are not wrong.

Or Web Developers and Architects can look ahead towards things they do *not* know. It is true; many Webmasters don’t know HTML, much less how to wrap their data in RDF. There is little out there to entice them to do so. What the Semantic Web needs is endorsement – not in theory, but in practice. If either the Open Source community or Microsoft were to build Semantic Tools into their suites, it would be a heck of a lot easier for the Semantic Web to form. It needs that first stake in the ground.

With Google moving as ominously as they are, it would appear to me that Microsoft would want to consider embracing W3C standards and building Semantic Web tools into SilverLight, MOSS, .NET while Google indexes and makes available Google Documents and other immediately free tools. Google is throwing a heck of a lot of free stuff out there, while owning it all. I do not want my WWW to be as Google dictates. I want it to work for me, for you, and for You. Google is a business. They provide a service. They also make some people very wealthy. I do not want the WWW to turn into a de facto proprietary landscape. That would not be good.

Ironically, I think the way to avoid this may be to get THE proprietary system – Microsoft – to build in Semantic Tools and take the control of data away from the indexing machines.

And let’s face it; data is not just bits, bytes, and text. It is meaningful.

Maybe it isn’t quite as it seems Andrew Layman worked on the original RDF spec, and he is a Senior Program Manager at Microsoft. It would make sense to me that they were doing, behind the scenes, what Google is doing right in our faces – planning to run the WWW.

As soon as we see SilverLight contain RDF tools, I will smile a little inside. People will be writing applications instead of HTML pages, and the applications will be a much better platform for schemas, Ontologies, and Semantics than a layer imposed onto HTML.

Google already bought Applied Semantics – natural fodder for their AdSense platform, and can do very obvious things with context. I don’t like the way it is all unfolding. And forgive me, but I can’t put my finger on exactly why that is. Maybe I have the feeling that people are playing dumb.

Best,

Josh Milane

MIT Technical, Boston

The Semantic Web Model, as proposed:

High-Level Requirements; The Good, The Bad, The Ambivalent

During the Discovery phase, High-Level Requirements can be a fair way to ascertain your effectiveness. If stakeholders sign off on your High-Level Requirements, you know you are not totally missing the boat. It is a good way to make sure you don’t put too much effort into doing more detailed Requirements that are not accurate. It also helps you identify the “nice to have” Requirements versus the “must have” Requirements.

This is what they tell me. I dont believe it at all.

First, a Requirement is something that is required. If a Requirement needs to be removed from the scope of the project because of time, budget, or other constraints, it is cut. It does not fall away because it never really mattered all that much and was a “nice to have” to begin with. It was a Requirement. Now, it has been cut from the scope and methodically, deliberately, purposely removed from the list of Requirements. There is no such thing as a “nice to have” Requirement, although many folks who teach Requirements Analysis would have you believe that there are.

Requirements are required under the contextual scope. If they are removed from the scope, they are no longer Requirements.

Now, there may be reason to note which Requirements are more important than others so if it comes down to it, scope items can be removed with intelligence. You can cut an expensive scope item if you need to, and you can know that item A is mandatory and item B is mandatory but if need be, item B can wait. Or, while it is mandatory under the current scope, we can go back and manage stakeholder expectations, explaining why it has been removed while making it clear that it was a business decision, not arbitrary. Still, I maintain that our fated Item B is a System Requirement. It is required against the project baseline. We have simply adjusted the project baseline – and as you know, baselines adjust, shift, and change.

A shifting project baseline is normal. A non-required Requirement is not.

High-Level Requirements do very little good in and of themselves. While they are the PM/BA equivalent of sticking your toe in the water, you are going to have to swim. Talk to your stakeholders. You are supposed to be doing Discovery. There should be no need to stop at High-Level when the client wants their system documented, not their general intent. The Business Case will do enough towards that end. High-Level Requirements are, in a way, cowardly.

There is a major caveat here; when involving third party consultants, it may be very beneficial to have them draw up High-Level Requirements. Ideally, this would not be the case, but reality is that even the most well-respected consultants sometimes get it all wrong. What I object to is a *deliverable* consisting of High-Level Requirements that carries a price tag.

I know I may be alone in thinking this, but that’s okay. I simply do not see the point in wishy-washy Requirements and timid documentation. We are here to build systems and to earn our money. We are not here to create artificial deliverables or Requirements. Project Management and Business Analysis get a bad rap as it is. I cannot tell you how many IT professionals I have encountered that consider Project Management a pseudo-skill, a collection of soft skills, a discipline without metrics to gauge its efficiency.

PMs can be the people that make or break the simplest and the most ambitious projects. Act with Boldness. Roll your sleeves up and get involved in your projects.

A little venting, today.

System Requirements probably need to start at a High Level, but they are not worth much of anything until you drill down a bit. Functional Requirements at a High Level are just a collection of generalizations and broad swipes at meaning. Consultants and professionals have no business billing for the delivery of a High Level document. They can be called Roadmaps, Development Guides, or masquerade as Statements of Work that trap the client and provide the consultant with carte blanche. They are bad news and bad business, in my opinion. All too often they are “Get Out of Jail Free” cards for unsavory consultants. You sign off, because they are accurate, but then the consultant is only bound to the High Level. Big deal. They may not present you with anything else to sign off on besides the Statement of Work and Contract. Be sure you know what you have coming in regard to documentation. Documentation may be all you have to fall back on.

That said, if the MoSCoW approach is to be taken to heart, it should be a guideline and not a rule. In my opinion, as of today.

Best,

Josh Milane

MIT Technical, Boston

MOSS (SharePoint 2007) and 508 Compliance, Accessibility Standards

I will write more about this later, but I am putting it up now as much (or more) as a reference for myself as a post that may help folks. MOSS 2007 is an improvement to SPS 2003 in regard to Compliance, and this is a very handy chart for those of you concerned with being compliant.

Support Open Source!  Or at least, please support Compliance…

Specifics on 508 Compliance can be found at the Section 508 Website

Specifics on W3C Compliance can be found at the W3C Website

It is interesting or at least noteworthy that the W3C standards and not the same as 508 Standards. The W3C standards are more rigorous, so the argument goes that if you follow their guidelines and CYA in regard to what they have put forth, you will be okay with 508. I will look into this further.

The following chart was lifted from: www.chandima.net with regrettable impunity:

Josh Milane

MIT Technical, Boston

Requirements, Risks, UnOffical Projects, and Pricey SharePoint Consultants.

This has been a challenge. I am involved with a 2 million dollar project that is under tremendous time constraints. The project itself is a MOSS (SharePoint 2007) project, and it is very stressful because of a variety of reasons. Let me enumerate some of them, if only to vent.

1. This is not really a SharePoint project. SharePoint vendors were solicited, came in, did a good job at convincing people, and maintained momentum. They did a great job. The company hiring them might not have done a great job.
2. The PMO in place at this organization was led by a person who did not know what a Use Case or Risk Assessment Document was. I did not know this when I came on as a consultant and was in fact told that there was a brand new methodology in place. I saw it, on paper. It looked like a cross between RUP and something custom (that I assumed was related to Health Care project milestones – since this is a Health Care company). I should have asked more questions, but the truth is, I like this organization and believe in what they do. Whatever the state of their PMO, I want to be involved.
3. A methodology on paper is very very VERY different from a methodology that has been accepted by the organization and is understood. We have this paper methodology, but there is very little understanding of the WHY.
4. This project involved building a system. A big System. The system should be capable of producing templatized “child” websites that share a common feature base but can have these features turned on/off and be able to receive totally custom modules when called for. It should also incorporate workflow management, document management, and CMS-related functionality. The team decided upon SharePoint 2007 before I came aboard. I did not know that
   • There was no official signoff on SharePoint
   • No Risk Assessment had been done
   • No Cost Analysis had been done
   • No forecasting had been done in terms of cost or staff or technology
   • Although meetings were taking place and money was being spent on this project, it has yet to be signed off on. There is no Project Charter. Not even a Statement of Work.
5. Development and Scoping of this system has been outsourced. The theory (the incorrect theory) was that it made sense to have MOSS specialists do the Requirements Documentation. The outsourced agency has spent 2 days on-site and come up with a “High-Level Requirements Document.” This document has cost the company $20k. It will reveal nothing we do not already know. The consulting company has ignored internal documentation regarding the “child sites” and has instead focused MOSS. Here is a typical conversation:

Us: “We want the breadcrumbs to reflect their MySite at the top level, and we want content to open within the body of the MySite page.”

Them: “Well, you can’t do it quite like that. Let me tell you how SharePoint does it, and why it’s really better this way…”

Us: “Okay, well… let’s run this past Design, Bill, Sarah, Ed, Development…”

So of course, this MOSS spec is being built by an outsourced agency while we run around internally and have meetings to see if we want them to do what they are already *doing*

There are several obvious problems here. Early on, I raised the issue of a Risk Assessment. I was told that we needed to wait until the system was scoped. I persisted, saying there were risks inherent in the technology and the engagement with the consultant as well as the definition of the project as a whole and the fact that there was no Project Charter, Communications Matrix, or even internal Project Code. T

Now, $60k has been spent on a SharePoint 2007 document. Not a Requirements Document. They have produced a proposal, and we have paid for it – which is fine and dandy, but it is a proposal for a MOSS solution, not a technical solution. It is not a PORTABLE Requirements Document. It is a very high level SharePoint blueprint.

The platform and child sites must be up and running by February.

What I have forgotten (and this is a bad thing) is that everything the consulting company stipulates that is dependant upon a specific techology begs an Assumption that needs to be documented. It seems like an awful lot of work has been created by going down this path. Not only is our documentation biased, it is unsupported and requires more documentation. Lots more documentation. Makes you ask, “Why do we do all this documentation?”

At some point, it is a matter of CYA, yes.

But documentation is supposed to be USEFUL. It is supposed to have UTILITY. If people create documents and the documents are not scrutinized, used to make business decisions, used to shape solutions, or used in some way, the PM/BA is wasting their time. This consulting company is creating a lot of wasted time. Time would be better spent doing real discovery, real Requirements Definition for the “child” sites, real analysis upon common features, the deltas between them, and real cost/benefit analysis. Earned Value Analysis. Present Cost Analysis. Common Sense Analysis. This all should have been done a long time ago, and yes – so what, it isnt done… do it now. However, there isn’t enough time. There isn’t enough time to do this project correctly. A major deliverable – the completed platform and child sites – is Feb 1, 2008. That is 6 months away.

So this is about damage control as much as it is about being hyper-aware of this road we have chosen and the obstacles, costs, and other gremlins that lie in wait.

This post was a venting session and I don’t expect people to get much value from it.

As I said, I am being utilized as a technical consultant on this project. I am to ensure that the PM is covering herself in regard to the technology aspects of the project.

We will be okay. It will just take a lot of hard work, intense conversations, and long nights of me writing dot notated documents and forcing people to sign off on them before the consultants build *anything*.

Josh Milane

MIT Technical, Boston