In addition I think the following also needs to be taken care of (atleast for development projects)

1. Baking Period – Most of the times a specific portion/core of software requires X amount of CONSTANT TIME, this should never be a variable and needs a CONSTANT effort Y & cannot be distributed/halved. I would like to call that as Baking Time because it’s very analogous to Baking a cake or bread.. No matter what, the cake has to be baked X amount of CONSTANT Time and Y Number of Oven capacity. Else we end up with either greasy or over-burnt Cake. Similarly it’s critical for the architect/lead to find out such piece of software and ensure that that portion of software gets that time.. the X could be time combo of brainstorming + ideating + design + POC + Unit tests + analyzing alternatives + analyzing NFR et al … and Y is the number of devs required to do the task. If it is decided that it’s better to be done as a timeboxed activity by 1 resource so be it… once this core piece is allowed to be baked properly we can always add icing, bells, whistles et al.
The Project Manager should understand that this is done for common goodness and spending a quality time on this 10% piece of work might have a good impact on the remaining 90% of the product. It could be a pressure but PM has to understand and have his foot on ground to provide such a quality time to the team. Again TRUST is a big factor here!

2. The Real-Estate Broker Effect [Shortening Deadlines] – Few project manager have a tendency of providing false deadlines to the team. For e.g. the customer says total time to deliver is 6 months, the sales guy now walks in and sets the date as 5 months, the GPM sets the date as 4.5 Months, the PM sets the date as 4 Months, the lead sets the internal dead line as 3 months and plans to deliver in 3.5 months… Well the real scenario might not be same, but most of them have this tendency and in essence we tend to lose 50% of valuable time that the engineering team could have easily used to solidify the design instead of just doing plain code & deliver because they have a deadline to meet! This is more like Real estate brokers who hike the rates but in the other direction!

I wouldn’t say this is bad, but there must be an upper bound of 5% - 10% for the buffer time.. which is purely for unforeseen risk. In my opinion if the PM has a buffer time of 10% to 30% he sounds in-efficient in my opinion because he has not calculated all the risks and the project is definitely not in his CONTROL. Moreover it also says that he does not have TRUST on the Engineering TEAM, which is again disastrous!!

3. Governing the Dynamics - A Real Solid PM – It’s easy for any PM to pass down the Heat/Pressure he got from the customer and his Boss to the people below him i.e. his team (specifically on the deadlines). This is the first step when the PM loses respect from the engineering team. He is merely seen as a physical bridge or log of wood who allows loads of gas to pass through.. but a Real PM is someone who would never allow the engineering team to feel the pressure but still deliver successfully on date. There are many living examples of these kind of solid PM’s I can introduce you to…

How do they achieve this? It’s actually simple – They MANAGE the project instead of TRACKING the Project! i.e. each aspect of project is analyzed logically & analytically and they take a stance of if it’s good let the event to happen and if it’s bad they see who needs to be educated, educate them, provide alternate solutions and solve the crisis. Especially if it’s a customer to be educated the PM should have a real back bone to go back to the customer and say what’s WRONG and educate them. Which is definitely lacking in most of the incidents and we end up as a disaster!
In this case the PM is the Bozo who has bought down the whole show AND MONEY!! Any PM who says that “I CANNOT SAY THIS TO THE CUSTOMER” should be added to the Watch List

But any PM who Governs the Dynamics and does it with his own style gets loads of respect and glory from the engineering team, their boss and customer 

In the end… it’s all about governing the Dynamics!!

Just my 2 cents…

Can u please provide some basic details about how I start to design Metadata driven ETL using c#?

Thanks,
BJ

I’ve been thinking on the dynamic sql option and have come to the conclusion that dynamic sql might be quite okay provided all db access is through sps…

Basically we’ll need a sql call routing proc like route_call ( client name, proc name, param string) where all three are varchars. The proc maybe uses a lookup table to translate client name to a db schema name and then issues a dynamic sql – “proc_name params”

I have developed an ETL Framework which provides following meta data driven functionality:
- Automation
- Modularizing processing
- Data quality
- Recoverability of ETL job
- Auditing
- Logging
- Notification
- Ability to reprocess rejected records, files, or any other data source

I did not use MDDE, I did my own coding. This gave me flexibility to enhance the Framework according to my needs. Moreover, I am not a fan of SSIS transformations in particular. If a certain transformation can be done in DB, I go for it.

Thanks,
Jagdish Malani

I’ve just started down the path of looking into MDDE for a new project. I was wondering how your project was going and if you are using any tools to assist in this project. We will be using SQL Server 2008 (SSIS packages) and I was looking at the MDDE Studio on CodePlex. Have you ever used the MDDE Studio or are you coding your own?

Thanks,

Marc