I function as an EA and project manager, but not both roles at the same time because it's way too insane to try to do both simultaneously. All PMs I work with as an architect know that I am also a PM and teach the subject at the university-level, and my philosophy when in the architect's role is not to give PMs project management-specific advice unless they ask for it or under certain conditions, need to get straightened out and in extreme cases, removed.
One of my current projects is in flux because the sponsors and stakeholders cannot agree on requirements and scope of the project. There has been a continuous back-and-forth between the full-blown project and what is nebulously termed a 'prototype' with reduced features that may or may not become productionalized. Nobody knows at this point.
The full-blown project is also devoid of requirements other than some very broad single-sentence tenets that are not very helpful in developing the system or data architectures in any form of detail. There are no requirements, use cases, or stories to get one's arms around to do a design and data model, much less estimate how long such efforts would take.
So the PM of the project comes into my office and asks me to develop a work breakdown structure (WBS) for the data architecture/modeling portion of this project. For the non-PMs reading, a WBS is, simply put, a list of significant tasks that will be tracked and reported during the entire project. I told the PM that I have produced WBSes for modeling and architecture before, so it should be straightforward to reuse some ones I developed on other projects for this particular one. Then he made a request that I could not comply with: he asked that in addition to the task breakdowns, that I provide a time estimate for each. I refused to do so outright.
As he immediately objected, I asked him: "Where are your requirements?" Immediate heming-and-hawing ensued. He didn't have much (if anything) and he knew it. I told him that any estimate without some direction would be foolish because estimates often (make that always) get taken as reality by management. There was absolutely nothing to base estimates on, not even a swag. I also indicated to him that a major risk-event gets introduced in the project whenever 'estimates' are given on the basis of little-or-no information, or if that information is highly volatile and subject to major changes.
Then, as I suspected he might, he plays the 'Agile' card. "We are running these projects as Agile projects. The requirements development will be Agile also." Nice try, I told him, but while requirements can certainly be added, removed, or changed as the iterations progress, there has to be enough detail up front for the architects and development teams to make reasonable estimates. One sentence 'requirements' are not sufficient for the granularity of the estimations he was asking for regardless of the methods he promulgated.
A further probing of mine was why he was doing a WBS in the first place - since it's a waterfall artifact - when he claimed the project was 'Agile.' Dead silence. He knew I had him on that too, since he was trying to superimpose a waterfall technique onto the claim of being Agile. He launched on a discourse about how he was going to 'plan' every iteration up front, and deliver to management how many 'iterations' the project was going to take. That almost never works well in any situation, and I advised him that what he was attempting to do was break the project up into phases, not iterations. Not Agile, and not waterfall.
More like disaster - down the road of course. I ended the conversation by stating that when he had a more solidified concept, or 3 or 4, about what was to be built, I would be pleased to assist him.
This conversation happened nearly a month ago, and I'm still waiting, and so is he.