Stop posting to DylanWanOracle.BlogSpot.com

My personal Blog will move to DylanWanMuse.BlogSpot.com or DylanWanPMP.BlogSpot.com instead of DylanWanOracle.BlogSpot.com.

Many of my blog texts are not Oracle related. I may only post news from other sites to the DylanWanOracle site or stop this totally.

More about Friendster

I read some more articles about the online social network services. Friendster was founded in 2002. It has been almost four years now. （我有点后知后觉）

I like LinkedIn better. I think that the quality of the information is the key. However, it takes sometime to establish it.


http://en.wikipedia.org/wiki/Friendster
http://www.u5t.com/blog/user1/1/archives/2004/20.asp
http://www.klogs.org/archives/000579.html

Registered with Friendster

I learned this web site from my friend. It seems that the site is popular among college students.

Comparing the site with other similar I know, it was a little boring.

I also provides Blog service. I do not think that I need to have so many sites.

I do not know why they all provide same services. We are lacking creativity and imaginaion in this industry.

How to improve the software performance?

This is a very old topic. A very basic requirement for software development.

Here is an approach I know some organizations adapt:

When you write the business requirements and define the functional specification, in addition to the functional behaviors, you also write the performance acceptance criteria.

Something like this:

Action: Open the XYZ window
Type: Online
Expected response Time: 3
seconds

Action: Summarize the transactional data for reporting
Type:
Batch
Max Process Time: 2 hours

You can then do this testing during your standard QA process. QA should execute the flow, run the process and record the actual time. If there are variation, they should report as issues and the engineering team can fix the problem.

Sound good, right?

We can examine the approach and underlying principle from Deming's view, from his 14 principles:

3."Cease dependence on inspection". If variation is reduced, there is no need to
inspect manufactured items for defects, because there won't be any.
8."Drive
out fear". Deming sees management by fear as counter- productive in the long term, because it prevents workers from acting in the organisation's best
interests.
11."Eliminate management by objectives". Deming saw production
targets as encouraging the delivery of poor-quality goods.

If Deming is correct, the above approach will not eliminate the problem. The above approach is basically an inspection based approach. It does not lead people to focus on the root cause, but focus on the criteria. It introduces a belief that if we are within the range, there is no issue and we do not improve the product.

I think that the key is that the system does not respect people who can really contribute to the quality of the product. As John Wookey, our leader in business application development, said People -> Process -> Product. I truly believe this. I see the suggestions are provided by Deming as well:

1."Create constancy of purpose towards improvement". Replace short-term reaction
with long-term planning.
2."Adopt the new philosophy". The implication is
that management should actually adopt his philosophy, rather than merely expect
the workforce to do so.
5."Improve constantly and forever". Constantly
strive to reduce variation.
7."Institute leadership". Deming makes a
distinction between leadership and mere supervision. The latter is quota- and
target-based.

You need to change people mind set by asking them to tell you - how we can improve our performance. This should be a never ending, continuous improvement. The people close to the code knows. They at least know how to improve the process. You hire the right, smart, talent people, give them the responsibility, and trust them. I think that it is the way to go.

As a line manager of product development, I think that these are what we can do:

9."Break down barriers between departments". Another idea central to TQM is the
concept of the 'internal customer', that each department serves not the
management, but the other departments that use its outputs.
6."Institute
training on the job". If people are inadequately trained, they will not all work
the same way, and this will introduce variation.
13."Institute education and
self-improvement".
12."Remove barriers to pride of workmanship". Many of the
other problems outlined reduce worker satisfaction.

Here are the rest of Deming's principles:

4."Move towards a single supplier for any one item." Multiple suppliers mean
variation between feedstocks.
10."Eliminate slogans". Another central TQM
idea is that it's not people who make most mistakes - it's the process they are
working within. Harassing the workforce without improving the processes they use
is counter-productive.
14."The transformation is everyone's job".

LinkedIn

I have created my profile in LinkedIn.
http://www.linkedin.com/in/dylanwan

It provides a great service. Please join and we can be linked.

Found a SQL I wrote 9 years ago

I am excited to see that my response to the comp.database.oracle.server discussion group is still visible today.

I wrote a SQL on how to Find the nth row in a table

It seems that Google is hosting all the historical discusion.


真是凡走过必留过痕迹...

When to use the resource loaded schedule?

This is a question asked in a planning & scheduling class I am taking. I think that resource loaded schedule will be in the following conditions. Please put your comments if you have any different opinions.

1. You have resource constraints. The resource availability to a project will affect your activity duration and thus the overall project duration. You need to put the resource limits to come up a realistic schedule.

2. You want to know the cost and schedule trade off. Depending on the resource used, you may have different schedule and the resource does affect the schedule. The productivity and cost rate typically go in reverse direction.

For example, the resource A, who costs $100 a day may produce 10 items each day and the resource B, who costs you $200 a day may produce 15 items. If you have 90 items to be produced, it tasks resource A 9 days and resource B only 6 days. By using a cost loaded schedule you know that bring the schedule shorten 3 days costs you (6x $200 - 9x $100 = $300).

3. You would like to do the Cash flow analysis

I would like to know when the cost will be expended ahead of time and prepare my cash flow accordingly. I can use the project schedule to tell me when my procured items will be delivered and thus my payment schedule to my contractors and suppliers. I should also put the milestones into the schedules for knowing when I can invoice my customers and thus the expected payments from my client. If my project is delayed, the material is ordered ahead of time, I need to notify the client and the supplier what to do. Either delay the delivery and the payment or ensure that I have enough cash to pay for it even I cannot invoice my client.

4. The resource loaded schedule is typically not used unless the client is required you to produce the reports. The federal projects may require you to do so.

5. I guess that you are required to do a resource loaded schedule if you want to perform the earned value analysis.

Google Sitemap

I found an interesting tool offered by Google, inc.

https://www.google.com/webmasters/sitemaps/siteoverview?hl=en

I added my Yahoo! GeoCities site to it.

http://www.geocities.com/dylanwan/

I have not maintained my Personal web site for a while. If i have time, I may go back to maintain it.

It probably does not allow me to add the Blogger site to it since I need to have the privilege to create a file under a given directory.

Dylan Wan on Google

Hey! Check out this page I published using Google Page Creator.

Dylan Wan on Google
http://dylan.wan.googlepages.com/home

Oracle vs. SAP

I read a great article in SearchOracle.com on the comparison of Oracle and SAP ERP.

It is written by two experts in this area.  To sum up, here are their major points:

• Faun deHenry focus on Oracle's adaptability to change. 
• Joshua Greenbaum believes that SAP can provide a better industry-specific verticalization.

Oracle Fusion exactly reflect what they said.  Oracle Fusion Architecture will bring customers the following:

• Greater Business Insight
• Adaptive Business Processes
• Superior Ownership Experience

This is best described in Jesper's blog- The Design Philosophy of Applications

The recent acquisition of Siebel not only brings Oracle a leading CRM software but also brings the industry specific solutions.

I feel that all these give the customers a very clear answer to the question SAP vs. Oracle.

What do you think?

Test

I cannot access my own blog for some unknown reason. Can you see it?

% Complete methods from Accounting and Project Management perspectives

I found a great discussion on difference thought of percentage completion between accounting and project management in Earned Value Management's Noteboard -> % of completion method in GAAP

I want to summarize it in below:

• For accounting purpose, revenue, expenses, and gross profit are recorded based on the percentage of completion of the project.  It is officially defined by GAAP.  Both input based (cost or effort based) and output based (work quantity based) percent complete methods are allowed under GAAP. Although the former method is more familiar to accountants.
• There is a disconnection between the accountant and the project management.  The focused problem they tried to solve are different and the tool and technique developed are not well linked. Therefore, there are hardly softwares can handle both views.  The problem can only resolved via seamlessly integration between project cost control and project accounting system.
• Some project accounting systems do not know earned value since the cost and revenue data captured in the accounting systems are not used for project control purposes.  The actual cost and revenue, plus the estimated cost and revenue based on the % complete method (unbilled receivable and unearned revenue) can be recorded as accounting entries.
• The project management discipline, on the other hand, does not deal with revenue or profit.  They believe that project management is to ensure the cost is not overrun and project is finished on schedule.
• Accountants sometime mix the % spent with % complete since they do not really know the project performance.  However, it is incorrect to say that GAAP requires % spent or only accept the cost based % complete method.  They just do not deal with this in such detail.  If I am a owner, I definitely don't want my client to bill me based on % spent if they know the current baseline is unrealistic and a design change is under the way.

The Top 12 Product Management Mistakes

I found an excellent presentation done in Silicon Valley Product Management Association - The Top 12 Product Management Mistakes.

Here I put the top five from the list and added my own observation and experiences.

Number 1: Confusing Customer Requirements with Product Requirements

Many products are built by working closely with one or few customers.  We let the few customers to drive the key features.  It is a good to gather customer requirements to establish the product requirements. However, we need to make a differentiation of the requirements specific to the customers from those for everyone.

Number 2: Confusing Innovation with Value

This is another extreme. The product design is engineering driven. There are good idea from engineering teams.  However, we need to make sure that the creative feature are solving the real business problem.  Sometimes, the product is over engineered with a set of features which nobody is using.

Number 3: Confusing Yourself with Your Customer

Some of us believe that the product manager himself or some upper management know what the product requirements are. We use the internal source instead of the customers to validate the requirements.  What we come up internally are just assumptions.  Assumptions need to be validated to be the true requirements.  It is very dangerous in my opinion especially when we face someone internally who pretend they know the product requirements and make very assertive calls.

Number 4: Confusing the Customer with the User

This is mistake happens because we do not focus on the big picture but only on the small product features.  The day to day direct users focus on how to make their job easier but may not  tell you what process can be automated and what jobs can be eliminated.

Number 5: Confusing Features with Benefits

Customers want to get the true benefits not just a set of product features.  The product features need to provide the benefits to them by solving their problem.  Adding features to the product do not always mean providing the benefits.  They are other important things - quality, simplicity, extensibility, configurability, scalability, etc.

There seems other good stuff from Silicon Valley Product Group.  I plan to read them when I have time.

The Importance of Analyzing the Enhancement Requests

The enhancement request handling is an important process. It is one of the most essential job of a product manager.

One thing that we should watch out are those solutions described in the enhancement requests. I have seen that many people try to describe the customer requirements together with some sort solutions. They feel that they are helping us and make our life easier. It is true that sometimes some kind of solutioning or describing the requirements in a way like describing product features help, but I can also see the problems. It becomes very dangerous when we have people from development side quickly response "Oh, yeh. I can do it." or " We can just fix this in this way".

Requirement and solution analysis is the job of a product manager or a solution architect. It is a step we should not skip. On one hand, we should appreciate the proposed solution the requester provides. On the other hand, we should make sure ourselves understand the business requirements. What is the business process, what are the business problems they are trying to solve. Sometimes, the requester do not understand our terminology and use the term not in the same way as we use. Clarify the definition of the term before jumping into the conclusion. If necessary, ask them to provide the details. We should avoid what we call "頭痛醫頭腳痛醫腳". We should try to fix the root cause instead of those symptoms.

Identify Constrained Resource for Project Resource and Portfolio

It is important to know what "constrained resource" is and how it affect the resource planning and project portfolio planning.

Resource Planning is about listing out the available resources and match it to the future project demands. It typically happens within a time window, such as a quarter, six months, or even a year. The result is to assigning the resources to each projects, identify the shortfall or surplus. If you are in the shortfall situation, you would need to do one of the following: add your resource supply by borrowing resources from a larger pool, train your resource to the required skills, hiring permanent employees, acquiring temporary contractors, subcontract out your work, or kill some of projects. If you are in the surplus situation, you would need to worry about your resource utilization, and the long term profitability. In a short term, you can think retooling your resource, sending them to training, etc. In a long term, you may want to adjust the size of your pool. Resource Planning is highly related to project scheduling in the way that both need to deal with the constrained resources, which will be discussed later.

<>Project Portfolio planning is a set of process for making sure you are working on the right set of projects, by evaluating, selecting, and approving projects into your portfolio. Your resource supply limits how much projects you can do in a given time frame. The trick is how do you define the "resource".

I think that the most important concept here is to think the "constraint" and use it as the criteria to determine how you categorize your resources.

Recently we discussed about the difficulty we are facing. While we do have a lot of engineering resources overall, we still feel we cannot take a new initiative, which we really want to do. They key resources with the deep knowledge are already assigned to a critical project. We do not want to jeopardize the critical project. Because of lacking these key resources, we feel that we may need to delay the new project, or even delay the entire release. We end up decided that we need to use"named resource" for project and resource planning.

<>The key factor is that there are constrained resources. The constrained resources are those resources that cannot be easily replaceable. The definition of resources for resource and portfolio planning need follow this principle - whether the resource can replace each other. If two resources can replaced each other, we can see them as "one" resource with double capacity. If there are a pool of resources that can easily replace each others, they can be seen as "one" resource with multiple capacity. If there are resources that like commodity that you can buy or borrow, in other word, you can adjust the supply any time, you may not treat them as a "resource" for portfolio planning. These resource are still need to be tracked for resource planning perspective since they are against the overall constraint - cost.

On the other hand, if the knowledge of a product area is limited to few, or maybe just one person. The named person is the constrained resource. The demand For these constrained resources should be expressed separately in the project proposal. The resource demand and supply need to be matched at this level. The project selection decision happening in a portfolio planning cycle need to be based the availability of the constrained resource.

It is important for management to know where are the constraints in the organization. I think that a good principle I learned from TOC (theory of constraint) is that the focus of management / process engineering is to remove or reduce the constraints. What you need to look at is the throughput, not the individually productivity.

A best portfolio planning and resource planning solution should help you to determine what are the constrained resources. It should use the constraints with the target and objective you have and come up anoptimal collection of projects.

Outside the system, you may want to ask: Why do we have such constraint? Can we use tools such as "job rotation" or "training", to reduce thedependency on the constrained resources?

Agile software development process

I found that the Principles behind the Agile Manifesto on the web. Here are my comments to these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Agreed. Delivering the software timely is important.  If you lost the market window, you lost the customer.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

We still need the change control process. Development cannot work under a moving target.  Change control process ensure that the changes are evaluated and communicated. The change control process is even more important under Agile software development process.

We welcome changes because we know how to control it.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Keep the software working with the incremental changes and daily or weekly (short timescale) "build".  I think that the quantity will be better.  However, it may be that easy for a new development project.  The software industry is being consolidated and maintenance revenue is the focus of many firms.  I think that Agile process fit better for enhancing the existing software.

4. Business people and developers must work together daily throughout the project.

My interpretation is that this is the daily change control process.  Instead of having a weekly or bi-weekly huge "change review board", we need to have a delegated, being trusted, small group of people, consisting of both the engineering side and product management to make "daily" decisions.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This is consistent with my comment above.  The agile software process cannot be achieved if any single change requires a huge discussion and raised to the top to make an top-down decision.  "Trust them" is the key.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This could be a challenge nowadays since many if us work remotely.  However, I feel that face-to-face does not means that we have to be physically in one location of one building. Instant messaging, phone,  Internet conference can help a lot.  Since this is a daily change control process, we still need to record the changes, including what decision is made for what reason. 

7. Working software is the primary measure of progress.

This is consistent with the good project management principles. You need to break your scope of work into enough details for tracking, monitoring, and controlling.  Typically, the work should not be more than 2 weeks of your process collecting period.  The status will only be reported as "not started", "started/in process", or "finished".  If the task is in the "in process" more than one cycle, you know you are in trouble.  You can avoid the subjective measurement of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This seems a common sense to me.  I am not sure if I understand what they try to say.

9. Continuous attention to technical excellence and good design enhances agility.

Kaizen - Continuous improvement - the same concept as Deming described in his famous 14 principles.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

My takeaway is : Focus on the "minimal usable solution" we absolutely need to provide.  What exactly the customers are looking for.  Do not do more than that.

Sometimes, especially from architecture perspectives, we want to maximize the reusability or extensibility.  I think that the trend is that we should rethink about it.  The "Reusability", "extensibility", or any traditional "good architecture" criteria, should be justified with business needs.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

No sure what "Self-organizing" means.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Sounds like TQM - Quanlity Circle.

My blog is now listed in Blog Hub. If you like my blog, please submit your vote or write a review. Thank you.

Using Process Flow in Requirement Definition and Solution Analysis

Process Flow is a useful tool in describing the business requirements
and product requirements. They may be created for different
purposes: describing the business process or the user system process.

1. There are pure "Business Process" flows. These business
process flows describe the business processes happened in the
organization. They actually do not relate to the software
development. They help the system analyst to understand how the
business work. A business process flow can describe either the
current business processes or the ideal, the best practice. They are
not just only a system analysis tool but a business reengineering
tool.

One of examples is the project management lifecycle described in
PMBOK published by PMI. It describes the typical project
management processes to help the reader become a more successful
project management professional. Their models include different
levels of details. At a very high level, they break down the project
management processes into initiating, planning, executing,
controlling, and closing. For each high level process group, they
provide the detailed, 2nd level processes. For example, you can
find different scope planning, resource planning, activity definition,
activity sequencing, etc. under the planning process group.
PMBOK uses processes to describes the work involved in the
project management function and describe each in details.

Similarly, you can also describe the supply business flow as
create a procurement requisition, create a RFQ, receive quotes from
suppliers, create a purchasing order, receive shipment notice,
receiving goods, inspect the goods, verify the supplier invoice,
create voucher, send the payment, etc.

2. The System Flow is another thing. It describe the use
procedures. It describes step by step how a user may use a
system.

It can be used to describe how the current system is used or what
the system should support. It is a tool to describe the system
requirements. They can be independent from a specific system, but
the flow is created to describe the user-system interaction.

Submit to the Blog Directory and added the GetBlogs link

I just submitted my Blog to the GetBlogs Directory.

Negotiate the business requirement and make the scoping decision

As a product manager and a business analyst, you are going to
present the suggested scope to your development. Do you see
this is a "negotiation" process? Do you see that typically the
product management wants to get the items IN and the
development tries to get the scope OUT? Do you see that you
ever need to ADD MORE into the scope so you can GET MORE
after the "negotiation"?

I do not have a clear answer for all the above questions, but I
can see that these are two models, two types of assumptions,
and two different processes:

1. People playing different roles sometimes need to play the
devil's advocate. The best decision is reached via the process
of negotiation among the people representing different interests.
In the software requirement scoping case, the product manager
represents the "requirement" side, or the "demand" side, and
the development represents the "delivery" and the "supply"
side. The assumption is that we cannot avoid people having
different interests. Instead of trying to solve the conflict of
interests within one's mind, disputing, debating, discussing,
negotiating, and finally reaching an agreement is the way to go.

2. Defining the scope can follow the standard decision making
process and can be scientifically done. The assumption is that
there is really no conflict of interests. Both product management
and development are toward to the same goal - delivering the
right solution timely to satisfy the targeted customers. Making
profit for your organization in a short run as a mean to maximize
the shareholder's value in a long run. The customer satisfaction,
effort, time to market, risk of delivery, avoiding rework, and
quantity should all be considered. They can be considered in a
systematic way as an individual or a team effort. A product
manager who propose the scope should consider both side or
even more factors as mentioned above. The reasoning and
the justifications are discussed with the development for
ensuring the completeness of proposal.

I do not have an answer. I can see both models explain the real
world situation. What do you think?

ERP and Cost Control

Today is the first day of the AACE annual meeting. I attended the keynote from Joel, Primavera and several good technical sessions.

One of the technical meeting I attended is about the Project Cost Management and System Integration. It discussed what is required for an integrated cost control solution. They described that it should allow you to have best-breed of the following systems, while you should not compromise your cost control :

• Accounting
• Change Management
• Estimation
• Scheduling
• Procurement
• Time Reporting
• Contract

I agree with most of what they said about the cost control system. The presentation provided a very good overview of what project cost control system is about, and reach a very similar conculsion as one we did several week ago for my boss.

The most interesting topic in the presentation is that it compares different solutions:

• Spreadsheet based
• Cost Loaded Scheduling
• ERP

They concluded that none of these solutions is ideal. You should really have a separate, dedicated cost control system. I will agree with their conculsion if their assumption about ERP are true:

• ERP offers a project accouting solution, not really a project cost control solution.
• Project Accounting is concerned with expenditures and based on GAAP.
• You need to collect data and report against your chart of accounts, a single, rigid, non-project specific structure.
  
• You can only have a single WBS, which is in the cost accounting system and is not controlled by the project cost control people.
• ERP does not offer robust budgeting and forecasting functionalities.
• ERP does not provide the end user customization.
• ERP provided good "online" reports, but poor "printed" reports.
• ERP does not do trending or what-if analysis.

These may be true for some ERP systems or for the situation you may face 5 to 10 years ago. Unfortunately, most of them may not be true today. At least for the application I am being involved in now.

I am appreciated the analysis they did. It is still an outstanding presentation. It highlight what the ERP vendor should work on. I do strongly believe that customers are looking for an single integrated system that can address the needs described earlier. If they cannot find a single system from a single vendor, they will take a best of breed approach.

If you are interested in what they said in the presentation, take a look at their Project Cost Management Solution White Papers. They are very well written with good logic and reasoning.


.

AACE Training and CCE/CCC Exam

I attended the four day training courses and took the Certified Cost Engineer exam in the AACE conference.

The training is for preparing the cost engineer exam, which covers several topics, such as cost estimating, cost control, project scheduling, project management, and engineering economics.

This is the most tough certification exam I have ever attended. It is cross several disciplines and is very very mathematical.

• It tested the probability of the normal distribution. Fortunately I learned that in my undergraduate as a major in statistics.
• It tested "computer operation" terminology. It should be an easy one, but it is actually not. AACE has it own definitions for the terms, such as "byte", "operating system", "mainframe system", etc.
• It ask people to manually do the CPM scheduling using the PDM method. I learned this in the project management course for the PMP certification. The one tested in the CCC exam is more closed to the practical situation. It asked you how much you will lost if the task X is delayed for the N days. You need to do forward pass, backward pass, identify the critical path, etc.
  
• You need to know the different estimation classes. AACE has its own definition while ANSI has another. Each class is for different purposes and is under different range of details. This may be common sense for cost estimators, but definitely not for someone who do not do this everyday. You can use different method for different class. You have to memorize all that if estimation is not your daily job. You also actually need to do a lot of mathematics calculation in the cost estimation exam.
  
• The EVM analysis is the most easy one in the cost exam. All simple number calculation: SV, CV, CPI, SPI, and EAC. The hard one is to do the calculate for the productivity analysis. I almost miss this one. It asked questions about when you should which contract type. It is a very practical situation. I gave up this one since the answers are all very unclear. I selected to work on the mathematics instead.
• Out of the four parts. the engineering economics is the hardest part. I took some financial courses in the past and have been taught the different profitability analysis or the investment evaluation methods several times. The CCC exam has the most difficult question and requires a lot of real world knowledge. You need to know MARCUS as the depreciation method required by US IRS. When you do the cash flow analysis, it asks you to consider that deprecation, which may affect your income tax, and income tax saving should be considered as the cash flow. I have not seen this complicate question in any exam. Meanwhile, the property tax is your out flow. You need to compare buy vs lease situation. Financial calculator is required.
  
• Some of the exam questions are related to manufacturing, but most of them are engineering and construction related. I have never heard "battery limit" area. It mentioned in the exam and I missed that one.
  

Before you are siting on the exam, AACE requires you to send them a technical paper. Getting certified as a cost engineer is really difficult.

Value Engineering for Software Construction

Many years ago, I lerarned that the "Design Pattern" concept was borrowed from the building architecture field to the software architecture field. I found that it was interesting to see how the cross field interaction can bring the good idea.

This week, I am in the AACE conference in New Orleans, LA. AACE is an association for cost engineers, many of who come from the construction industry. I learned that in construction, people are very concerned about "getting the great value possible for every dollar spent on captial construction". A set of "Value Engineering" or "Value Analysis" tools and techiques were thus developed to address the needs. Basically it is used to select the best design concept, which can yield least lifecycle costs. The concern is not just to gain the cost saving for the project during the construction phase, but for meeting operatability, maintainability, reliability, durability, and other criteria from the owners.

In software construction, we have the same concern. John Wookey called it "Superior Ownership Experience". Can we borrow the value engineering methodologies to the software application architecture and construction process?

Business Requirement vs. Product Requirement

Are these two separate requirement documents? Some people believe so while others do not.

I feel that we should separate these as two separate deliverables.

The business requirement document is sometimes referred as the marketing requirement document (MRD). It discusses the requirements at a very high level from a business perspective. It describes the problem that need to be resolved, the market opportunity, and sometimes the competitor offerings. It justifies if a development project should be initiated. The business requirement document is not tie to any given development release and should avoid using the product specific terms. Sometimes the requirements are described in a such neutral way that you cannot tell which module or applications will be impacted. Actually, the business requirements is more like a RFP from some prospects. It is a user view of the solution.

The product requirement document is sometime referred as the product requirement specification or functional specification. It describes the expected functionality from a product. It is an outcome from the requirement analysis process. It interprets the business requirements by mapping and describing them using the product terminology. It is the document to communicate the business requirement to the product stakeholders. A product requirement document should be written with a product release in mind although not all features identified need to be scoped in. The key point is that the detail scoping decision can be made based on the product requirement document. It is the product requirement document identifies the scope of a development project. In the PMBOK, the product requirement document can be regarded as the scope statement for initiating a development project. It defines the features and is the product view of the solution.

At some stage, the product requirement should be baselined for functional design. It should be subject to the change control process for scope control. Scope creeping can thus be avoid. However, it worth mentioning that the requirement analysis is a iteration process. You should not be too rigid on changing the product requirement during design phase. You should not feel hesitate to contact customers to clarify the requirement.

Here is a very good document I found on the web.

Structure mapping

Moved to my new blog site: dylanwan.blogspot.com - Work Breakdown Structure Mapping

Chinese

中文嘛A通

Link from google

This is a link to google.

Fwd: Try gmail

Gmail allow me to post from the Internet without using netscape.

I like it.

Center

Left

Right

Highligh this

Make Bigger.

or small.

reasons to start a blog

Mia vita: Benvenuto!!

Current Visitors

I should study how to add the "Current Visitors" section.
Sexy Pix Mega Post: Oscar HQ pictures: "Current Visitors"

this is a chinese blog

��TrapNest�� Bilingual Version

this one has a good format too.

a very plain format - northern apostolic mom

Try fonts and other formatting.

Yahoo! did not do the HTML link well.  I can add a link from the netscape email client. 

• one
• two
• three

How about this

I am using the fix size font.

And indentation

this text should be indented.

:-) ;-) :-D

---

Try a table as well

col1	col2
cell1	cell2

Hope you can see the image.

Try from Netscape

Here is another link to oracle.

Another test

Test

I want to add a link

"Link" from email is not working.
Here is a link to www.oracle.com

Can I use a hyperlink?

Here is the <a href="http://www.oracle.com">link</a> to
oracle.com.

Try one more time

I do not like to see "yahoo".

Try to post from an email

This message is posted from an email.
.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Start Here

This is my first posting. Just a test.