Project Methodologies

Tips for Implementing Project Methodologies (found on the net)

"What is a methodology"?

A methodology is a step-by-step method for delivering projects. It describes every step in depth, so that you know what you have to do to deliver your project. By following the same steps for every project you undertake, you'll save time and effort on projects.

"How do I select a suitable methodology?"

The first step is to define your requirements. You need to think about what it is that you want from your methodology, the type of content it should contain and the way in which you intend to use it.

For instance, your requirements might be as follows:

• It needs to contain a complete Project Life Cycle
• Every step in the life cycle should be described in depth
• Each step should have practical templates and examples to help to complete the step quickly and easily
• It needs to be based on worldwide project standards
• It should suit all project types and sizes
• It should be easily customizable.

The next step is to review the methodologies used currently by your organization. Why reinvent the wheel if you have something that works in-house? Look at every methodology used and compare them to your requirements to see if there is a good fit.

If there isn't a good fit, then you need to look at purchasing a suitable methodology toolset. Start by searching the term "project management methodology" in Google and comparing each methodology you find against your requirements.

If you find a methodology that has an 80% fit, then that's great. Just make sure you can customize the remaining 20% to meet your requirements.

Where you can't find a suitable methodology toolset, your only option may be to develop a methodology from scratch. This will be more time consuming and expensive than adopting an existing internal methodology or purchasing a third-party methodology.

"How do I implement my selected methodology?"

Whether you've purchased or built your methodology, the next step is to implement it for your organization. This involves:

1. Creating an Implementation Plan.
2. Customizing your methodology for each project.
3. Training your team to use the methodology.
4. Making sure your team follow the methodology.
5. Constantly improving the methodology.

Scrum Methodology

Agile is the best methodology,  while I have mastered scrum based on the patience and intelligence of the people involved.

Some info from Wiki would be very helpful here..  ( referencing with a link )


Here is a good article you should not miss.  Excellent.
http://martinproulx.com/2009/07/02/what-is-scrum/

Software Technical Architect

From a business-centric perspective, architects should be corporate assets, not code designers. There are five dimensions to a software architect role: 1. technology 2. consulting 3. strategy 4. organizational politics 5. leadership Technology should consume perhaps less than 20% of an architect's day. Projects don't fail because of bad design or ugly code or improper/inefficient testing or even a wrong choice of technologies. There is no such thing as a perfect technology for a task at hand, only bad leaders and poor visionaries. The above mentioned are but consequences of poor organizational choices and a lack of focus. And patterns? They are but a convenient communication framework of the day. Should we know it as architects? Yes. At least we should know where the repositories are, and how to look through the repositories for a match with a task at hand. Frameworks change. For example, is MVC in Struts really M-V-C? Some people would say no. Unfortunatelly, those are few in between, for Struts rules. Oh no, or is it AJAX that rules? Or maybe SOA and REST and web services? No, no, it's OOP and generics, and AOP. One interesting thing happened with software engineering after WWW hit the mainstream. Some became gods in their own minds, and everyone became an architect. Vanity rules, and it will come to bite the software industry worse than the dot.com crash did. For Bankers are not a very patient bunch. Remember Occam's razor. "one should not increase, beyond what is necessary, the number of entities required to explain anything." That's wisdom. Now, you Mr./Mrs. Architect, who got bitten more than once by your own vanity and have learned some valuable life lessons, you go and explain this to a young hotshot who thinks he's got it all down after two books read and three projects completed and left for someone else to maintain. Someone should teach a class titled: "History of software art" and make it a mandatory read.

From a career path perspective, the role of an architect progresses from developer, senior developer, solution architect and architect. Sometimes a senior developer can jump few steps and become an architect based on varied skills and experience. So, asking questions in core java tests if the candidate has followed a career progression path. Next, there are several types of architects in IT, not just J2EE architects. One can be a data architect, application architect, solution architect, operational architect and so on. These roles may or may not exist in all companies and some roles are combinedly assumed. When selecting an architect, it is important to test several areas right from business and functional requirements to troubleshooting a deadlock issue in a distributed transaction and things in between. Architects should have all skills. Most important thing is the ability to research and development, which is true particulalry in this age of "pattern a week, language a fortnight" (Patent Pending :-)) type of discoveries. This proves, the would be architect has 360 degrees experience gained the hard way in IT shops.

The scope of assessing an architect varies based on the role he/she is likely to play(Application/Domain Architect, Solutions architect and Enterprise architect). So mere asking some technical questions like final, finally and finalize will not help to select a good architect. Questions like the below one might be more practical:
For an Application Architect : 1. Give a project requirement and ask him to depict the Application and System Architecture models then start ur question based on it... that will give a good idea.
2. All NFR questions.
3. Design methodologies used, issues, solutions.
4. Give a scenario ask them to design... - classdiagram, seq or deployment or component etc...
5. Questions on design patterns
6. Question on Team lead and peer interaction, presentations.
For a Solutions Architect: Questions about the project dependent items - like Infrasture team, security, development team - should be asked.
For an Enterprise Architect: 1. governance capabilities
2. Future roadmap
3. procurement
4. compare products
5. Business Interaction for new proposals and vicecersa

Wish you good luck in your recruitment now in future.

Business Objects v/s Microsoft BI

Business Objects (BO) is platform agnostic and so is MS BI to a "certain" extent. In BO, you can build a semantic layer (named Universe) and hide technicalities from the users. Users in turn can build their own reports using this semantic layer using a module called Web Intelligence or WebI (thin Client over the web). What makes the semantic layer so powerful is that it hides core stuff from the end user and you as a designer / architect give meaningful terms within the semantic layer which is visible to the end user. Security can also be built into the semantic layer. In MS BI, there is no such thing as a semantic layer. You build a report using SQL or a Stored Procedure and publish the report which can then be consumed by the end user. Both technologies allow report scheduling and delivery in various formats (Excel, PDF etc.,) although BO I personally like BO's report delivery mechanism.

BO supports report bursting (only relevant people can see relevant data), although, report bursting is not to be confused with security. MS BI has no such feature yet. (MS BI is still evolving in comparison with BO)

BO WeBI reports can highlight data changes between various refreshes, MS reports cannot.

MS BI includes OLAP technology. In BO, you can expose the OLAP DB as a universe to the end user. MS BI allows end users to access OLAP cubes via Excel Pivot tables. This is an excellent and an extremely powerful medium, especially to end users who love MS-Excel.

As for costs, BO is fairly expensive (depends on the licensing model and based on the modules you select such as Dashboarding, Scorecards, OLAP, Web Intelligence etc.,) MS BI can also be fairly expensive and if you are licensed to use the Enterprise edition of the SQL Server Database, you get OLAP, Reporting services as part of the package.

BO is fully supported on VMWare platform thus reducing the cost of running it on a physical server. This also helps you recover and be up and running quickly in case of a disaster. MS technology on the other hand does not explicitly support its DB / infrastructure on a VMWare platform since MS-HyperV is MS's own virtual technology. Installation wise, BO is a little involved than MS.

MS BI Includes an ETL layer called SSIS (SQL Server Integration Services) which you can use to get data from heterogenous systems. SSIS is part of SQL Server Enterprise edition and you don't pay extra for it. BO has its own ETL layer called Data Integrator and you pay extra for it since it is not bundled with BO.

There is always a learning curve with any BI tool, be it MS tools or BO or Cognos etc., MS technoloogy in my opinion requires a technical person to build reports for end users. With tools such as BO or Cognos, you build the semantic layer and using which an end user can build many reports. One very important point to remember when you build BI / DW subject areas for your company, please ensure your end user needs are met. "You build it and they will come" approach will not work, especially with a BI implementation.


The key benefits of the MS stack is a consistent security model and the ease (from a developer standpoint) of creating solutions. It is not easy for end-users to create or derive information and reports without the involvement of IT.

The key benefit of the BO stack is "ease of use" from an end-user perspective (with minimal training and Web Intelligence, end-users can be very "productive".

I put these in quotes because with the universe model (or a semantic model from other vendors... this is not a BO-only problem), it is as easy for end-users to get the wrong answer as it is for them to get the right answer. There is almost no way for end users and it is very difficult for IT professionals to understand why they got the right or wrong answer. Because everything is hidden behind the Universe model, tracking from a report back to the base data is a non-trivial task.

The security model under BO is highly fractured. Universe-level security bears no resemblance to report security which bears no resemblance to database level security which bears no resemblance to portal-level security. You have to get all these right to keep your data secure.

Because BO relies on other vendors for the data store (this may change now that SAP owns Sybase), performance tuning is also highly complex. There is no facility for aggregation (like Analysis Services or other OLAP platform). In order to get pre-aggregated results, you have to work with DBAs to manually create aggregation tables and integrate them into the Universe.

Managing and maintaining BO is also very convoluted. You have to understand that it is an amalgamation of products from Business Objects (prior to the SAP acquisition), Crystal Reports (prior to the SAP acquisition, CR was acquired by BO) and other vendors. They each have their own vision of security, management and administration. Then there is the data-store level (see above).

You need many disparate skills to do a full BO implementation.... Universe modeling/design/implementation, data warehouse modeling/design/implementation, Java skills, Tomcat (or other J2EE platform), security (AD integration is problematic, integration with other LDAP platforms is a nightmare).

Overall, I prefer the Microsoft stack. I acknowledge that it takes more effort from IT to get a set of reports going and new reports often require someone from IT be involved, but overall it is a more managable, more secure and less expensive solution. I see Business Objects as a consultants dream.... an endless font of billable hours.

While I agree with Philo that SSAS is an aggregation layer between transactional data and the business user, it is absolutely not a semantic layer.

A semantic layer provides translation services between an underlying data store and business-level language (the business semantics that end users will be familiar with). BO's Universe semantics layer does the translation between a business semantic (an Order, an Employee, a Line Item, etc) and the underlying data store (tables, joins, aggregation tables, etc).

 Licensing and hardware costs fall under the heading "initial acquisition costs". Throw in the consulting and knowledge transfer costs (training, etc) and that will give you a pretty complete idea of what the initial costs will be for a solution (Business Intelligence, Data Warehousing, ERP, CRM, buying a car, buying a house, etc)

In any IT project, the bulk of the costs are day-to-day operations over the expected life of the solution (generally 3-5 years). Initial costs may be as little as 10% of the overall costs.

I'd rather spend $100,000 initially on a system that will cost me $500,000 over the expected life of the solution than $75,000 initially on a system that will cost me $750,000 over the life of the solution.

Yes, there are budget realities to be considered (I may only have $75K in my budget this year and no chance of getting the $100K... but amortizing the higher cost into the future may be acceptable).

What I like about the Microsoft stack is I can leverage skillsets that I already have in-house (SharePoint, Windows Server, SQL Server, .NET developers). With BO, I would need headcount dedicated to BO (Universe design, implementation, maintenance, security). Since BO skils are not generally transferrable to other skills I need, those extra heads blow the budget for me.